Service layer and project structure in ASP.NET MVC 5 without repository and UoW patterns entity-framework entity-framework-6 service-layer

Popular Answer

If you don't need to construct a universal data access method, there is no reason to adopt the Unit of Work paradigm with Entity Framework. If you were: only then would you:

  1. utilizing a data access method that doesn't automatically support a unit of work pattern (EF does)
  2. Eventually, you'd like to be able to switch data sources, but it's not as simple as it might appear because it's very difficult to avoid introducing dependencies on particular data technologies even when utilizing a unit of work (or even because you are).
  3. You must be able to combine various data sources into a single atomic transaction.

If none of those apply to your situation, a bespoke Unit of Work is probably not necessary. On the other hand, a repository can be helpful. However, since EF6 offers mocking interfaces for testing, many of the advantages of a repository are also available with EF6. In any case, avoid using generic repositories unless they are merely implementation details for your specific repositories. Giving your other layers access to generic repositories is a significant abstraction leak.

However, I always utilize a Repository/Service/Fade pattern to separate my data and business layers from my user interface and business layers as well. A facade/repository/server interface decouples your logic from the specifics introduced by the Linq layer used by EF (Linq is largely generic, but there are aspects that are special to EF). It offers an easy approach to mock without having to simulate your data access itself.

You're generally going in the right direction... Let me clarify, though, that it's a good idea to use Data Attributes on your view models. By doing this, you can center validation logic on your model rather than having it scattered throughout.

You are correct that validation is necessary for business logic as well, however you made a mistake by assuming that validation should only be included in business logic. Every layer of your application needs validation. Additionally, the requirements for your UI validation may differ from those for your business logic validation.

For example, you might design a multi-step wizard for generating new accounts in your user interface (UI). This would require different validation than your business layer because each step only needs to validate a portion of the entire object. Alternately, you may stipulate that the validation requirements for your mobile interface differ from those for your website (one might use a captcha, while the other might use a touch based human validation for instance).

In either case, it's critical to remember that validation is crucial at the client, server, and different tiers...

9/11/2014 10:18:11 PM

Related Questions


Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow
Licensed under: CC-BY-SA with attribution
Not affiliated with Stack Overflow