0

So I'm trying to learn how to keep a good structure in a WPF application and having a hard time figure out the best way to work with BLL and DAL.

I already have a couple of models in my BLL, for example:

Customer, Account, etc

I'm also using MVVMLight toolkit to make things easier so almost all my models inherit from "ObservableObject".

Now I'm going to create the DAL and use Entity framework. As all my models use ObservableObject I feel I can't just move them to my DAL to create my tables (code first).

Would the best way here be to create almost identical objects in my DAL and map all the data to my old models in my BLL when I retrieve them? I know it's a bit of double the work and so but can't see how I can keep it more clean (other than stop inherit from ObservableObject)

MilleB
  • 1,470
  • 2
  • 19
  • 32
  • For any users not familiar with the above abbreviations, BLL stands for *Business Logic Layer* and DAL stands for *Data Access Layer*. – Sheridan Mar 11 '15 at 14:21
  • Typically, generated objects from the DAL should *not* be used in the BLL and so should be copied to BLL objects. Note that your objects in the two layers should not really be *almost identical*... your business objects should (or at least could) be hierarchical, unlike your DAL objects. – Sheridan Mar 11 '15 at 14:28
  • I see, yeah then I'm on the right track then. I have a short follow up question to this, is there any normal naming convention for this? I guess having "Customer" in both DAL and BLL can be a bit confusing. Normal to have something like CustomerBll, CustomerDto? – MilleB Mar 11 '15 at 14:47
  • One would be CustomerEntity for domain/BLL and simply whatever your table name for the DAL (especially if you are using Entity Framework) – EkoostikMartin Mar 11 '15 at 14:54
  • I personally prepend `Db` onto the front of my DAL classes to avoid that problem, eg. `DbUser`, but you can use whatever you feel comfortable with. – Sheridan Mar 11 '15 at 15:52

1 Answers1

-1

Entities like Customer and Account have to belong to the Domain model. It's recommended to keep your Domain agnostic of all irrelevant dependencies such as MVVM-blablabla. I would consider firstly how to remove a dependency on the MVVMLightToolkit from your models. You always can rely on INotifyPropertyChanged, sometimes it's better to sacrifice a couple of syntactic pieces of sugare. If you can avoid duplication, you should avoid it.

In the end, questions you raise are very dependent on circumstances, There is no one perfect remedy.

Consider to learn the following materials:
domain-driven-design-fundamentals
Eric Evans book on DDD

EngineerSpock
  • 2,575
  • 4
  • 35
  • 57
  • Thanks for comment and I'm going to check in to the pluralsight video later. I know I can remove them but I feel I lose more then I gain from it. Things I like with WPF is the easy binding to GUI and I rather have multiple models than trying to set up new events etc to keep the GUI updated. – MilleB Mar 11 '15 at 14:49
  • It would mean that your Domain is tightly coupled with WPF infrastructure. It's often is a very bad idea. – EngineerSpock Mar 11 '15 at 18:44