Menu
I have a ASP.net (C#) project that is using a three layer architecture. I started to use Entity Framework in my DAL and the question is to what extent classes generated by Entity Framework can be used in the Business Logic Layer?
It is a good idea to use them directly or should i create my own business objects and map to them from Entity Framework(db->O/RM->BOs)?
815
Entity objects encapsulate business logic The best place to write your business logic is in entity objects, because they consistently enforce business logic for all views of data, accessed through any type of client interface.
The business logic layer contains objects that execute the business functions. The Command pattern should be considered to implement these objects. With the Command pattern, each use case in the requirements document is implemented as a separate command or set of commands executed in the business logic layer.
DAL – Data Access Layer : provides simplified access methods to the DB. • BLL – Business Logic Layer : provides data processing methods. • WS – Web Service : provides simplified interface to access the BLL methods from any application.
Three Tier/Layer Architecture Design Components Data Tier is basically the server which stores all the application's data. Data tier contents Database Tables, XML Files and other means of storing Application Data. Business Tier is mainly working as the bridge between Data Tier and Presentation Tier.
In my opinion, the EF objects would be mapped to yours. This has a higher development cost, but gives the added benefit of persistence ignorance and decoupling. This decoupling can translate to significant agility and real world savings in the long-run, should the business need to switch to a different persistence solution. Without the decoupling, the EF objects can become deeply embedded in the BLL and even presentation layers, requiring a huge refactoring. In such a case, the business might not even consider switching persistence solutions, which could cause the business to be less competitive.
The decision to reap this benefit at the higher development cost depends on the amount of risk the business is willing to take. I suggest you consult with the project commissioners and use your best judgement to interpret their strategic objectives in a technical way.
105
It should be reasonable enough to use the generated classes as your Business Objects. The generated classes are partial so you can easily extend them as you please. Sometimes I find it a nicer option however to use interfaces.
39
I have just started on EF 2.0 (in .Net 4.0 beta 2) and it has the facility to use POCO clases as EF entities. i.e. You can now use persistence ignorant classes in EF 2.
I think this is not fully ready yet, as I couldn't follow the presentation from PDC 2009 when working in Visual Studio 2010 beta 2 but keep a watch out for this at ADO.Net team blog.
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
