2

im doing some self-study on architecture of a MVVM-light - EF Application im trying to build a product/Receipt like app. I have a Db/EF with a Product and Receipt Table/Entity in a many to many relation. then i have a DAL wich simply uses Linq to do simple CRUD.

the question is where and how to put my business logic in this app.

a couple of ideas came to mind

option 1 -make a ReceiptBo (Receipt business object) wich inherit the Entity Receipt class and Icollection(ProductBo) the ReceiptBo class would be responsible for adding Product,calculating total and subtotal and calling the Dal for inserting. maby this option seemed a little overkill.

option 2 -put the calculating methods in the generated Entity objects by using partial classes and simply using the BuisnessLayer to call the Dal. this would make the Buisnesslayer Classes obsolete in my opinion and im not sure that Entity classes should be used for Business logic at all ?

option 3 -make the Business Classes but dont bother using inheritance, just add products to the Entity's and do the calculations there and call the Dal for insert. wich seems simple but not very elegant.

option 4 -none of the above and im clueless

right now im not using WCF but the idea is that i want to make this app loosly coupled so that it would be easy to implement it and further extend it.

also im a little confused about what an Business layer is. in some examples it is more used like a Dal that also does the computing, then others say this is not done.

some help would be great. thx

ps: sorry for my bad english

Danubian Sailor
  • 1
  • 38
  • 145
  • 223
Stefaan Van Hoof
  • 19
  • 2

2 Answers2

1

Really, I would go simple here and choose a common multi-tier architecture designed as follows:

  • a data access layer (basically, your Entity Framework model along with all your entities)
  • a business layer that exposes methods to access to your entities (CRUD methods + any custom method that run some logic)
  • a service layer that exposes stateless methods through WCF (service+data contract)
  • the presentation layer (in your case using MVVM pattern)
    • Views (XAML pages)
    • ViewModels (C# classes)
    • Model is represented here by the entities that are exposed through WCF by the service layer

I wouldn't add any method directly in the entities. All methods are defined in the business layer, and exposed by the service layer.

ken2k
  • 48,145
  • 10
  • 116
  • 176
1

Usually I keep my business logic in my ViewModels, not my Models, and I view EF objects as Models. At most, they'll have some basic data validation, such as verifying length or required fields.

For example, an EditRecieptViewModel would validate business rules such as verifying values are in a specific range, or verifying that users have access to edit the object, or performing some custom calculations when a value changes.

Also, don't forget that ViewModels should reflect the View, not a Model, so not every Model will have a ViewModel of its own

Rachel
  • 130,264
  • 66
  • 304
  • 490