Last post Mar 11, 2009 01:20 AM by JonRanes
Jan 22, 2009 12:03 PM|temebele|LINK
I thought I will be able to find some good ideas on this ASP.NET MVC forum, assuming that developers using ASP.NET MVC are probably using ADO.NET Entity Framework for Data Access.
On the Entity Framework, the Data Access Components and the Business Entities are separated by namespaces. (Logically Grouped.).
If I want to implement business rules, I can still use partial classes with my business entities and inject my additional rules.
Different implementations for the data access are also possible by using the repository pattern.
When I create applications using N-layered architecture, I was used to having another layer (Business Layer) on top of my data access. That way Presentation layer is only aware of business layer and not data layer.
But with the Entity Framework, now that the entities live inside the data layer, Presentation is going to have to reference that data layer.
So does using Entity Framework eliminate the need to have a third business layer, because it really doesn't make sense to have another layer if anyways you are not avoiding the dependency of the presentation layer on the data layer.
How are you guys using it in your apps?
Jan 22, 2009 03:26 PM|RobSil|LINK
Rob Conery has an excellent sample app that you can refer to on this site
here. That sums up the tiers nicely. This is probably the best example of a good seperated architecture I have come across for ASP.NET MVC yet.
Since I want my DataStore to be 100% interchangeable, I always duplicated the objects the web sees vs. the objects a data source uses (as per the above link). Then you translate the objects between the two layers, usually in the Data Layer (again as per
the above example via the LINQ code).
Personally I also like to separate the tiers a bit more and create an entire validation sub-project whose job is to validate the objects the web-tier sees. This let's me remove that level of business logic into 1 neat package. I've written some helper
classes that translate the validation errors into a generic errormessage -> list association... so that on my Web-tier I can translate multiple validation errors into many flagged fields, but maybe 1 error message (e.g. "all fields required" with many fields
highlighted in red). It does require some minor validation duplication (e.g. non null DB field in an ORM class) but I like to think that the DB-applied validation should be seperate from my business logic, if at least conceptually, anyways.
Hope this helps,
Jan 24, 2009 01:37 AM|temebele|LINK
Rob, thanks for the reply.
I did follow Rob Connery's screencast and I also had email conversation with him. Both the email conversations and his screen cast were really helpful and I agree with you that it is one of the best compilations I have seen so far around MVC. Kudos for Rob
But if you have noticed in the MVC store front, the web layer references both the service layer and the data layer. According to Rob's project, even after creating separate sets of domain objects to be used by presentation, they reside under Model namespace
in the data layer. This was a little different for me because I'm used to a component referencing only the layer above it, or the common components to all layers.May be taking out the presentation model objects to a separate project will solve the dependency
issue. (So they will be like DTOs). But even in this case I believe there should have been a flexibility in EF to have a different project for business entities.
Now I see your point in that it adds flexblity interms of being able to support a different data source in the future. But unless there is a simple mapping mechanism from the presenation model to the EF conceptual model, do you think that it is worth trying
to create a different object in each Linq query. Also you have to re-map the objects trom presenation to conceptual when passing objects to be saved or updated.
I believe Entity Framework should have flexiblity to switch our storage model with out changing our conceptual model, hence achieving the flexiblity that you were looking for. I think that is a problem with Microsoft not adding that feature but it would be
costly to try to create our own second level of mapping.
Also, looking at the definition for repository pattern according to Martin Fowler, Repository
Mediates between the domain and data mapping layers using a collection-like interface for accessing domain objects.
If you look at EF, any class that implements the objectContext does exact same thing Fowler defines a repository should be. So I don't know may be the pluggablity for interchanging data sources should have been on the level of the ObjectContext,
though I'm not sure if MS provided that flexiblity with EF. Or may be it is right to have another repository pattern like layer on top of the object context ( as per Rob's sample app) and manually mapping and re-mapping the business entities created by EF
into our presentation model. As for me, it is kinda of tough to have a clean Presentation-Service-Data layering with EF, may be MS will fix it on the next release of EF.
What do you think?
Jan 24, 2009 04:59 PM|RobSil|LINK
I did notice the dual reference also. I can't speak for his motivation for the way he structured that aspect, but I was tempted to carve out the objects to their own tier but didn't do so at that time. I am still debating that step just for modularity
down the road.
The only reason that I would insist on keeping duplicate POCO objects is that some ORM tools are able to interact with your custom objects directly rather than generating their own form of them so in that respect they would be useful.
Anyways, to me it sounds like your really on top of things so I doubt that ultimately whatever choice you make it will be the wrong one. I can't pretend to be overly knowledgable with EF so can't comment on it that much. I also think that if you google
enough you can find blogs with well-worded arguments arguing various conceptual view's on this topic as well... so ultimately I think this just boils down to personal perference for most... assuming that due diligence to the basics has been applied of course!
Jan 25, 2009 12:33 AM|temebele|LINK
Thanks Rob. That is pretty much where I am right now.
After some googling I found that they have developed POCO adapter for ADO.NET EF.
Entity Framework POCO Adapter Updated - N-Tier Application Scenarios and Detached Entities
I think using the adapter would be much better than the mapping that we do inside the linq queries. I'm still looking to see how the POCO adapter works. But anyways if the adapter adds too much complexity for my project, I may just decide to stick to using
the EF business entities as my presentation model. Anyways for this specific project I don't expect moving to a different ORM tool in the future.
Mar 11, 2009 01:20 AM|JonRanes|LINK
I like Rob's style also. I was looking at patterns and practices trying to see if the repository factory could be used in any way to go along with the style used by Rob in the Contact Manager example. Since the repository factory project is deprecated
though that shot that. I looked at the current offering from patterns and practices and can't make heads or tails out of what they are offering, if it will be supported down the road or what.
I also am thinking of moving the repository and or the service layer out to another project. Does anyone who has done this have any feedback on this approach? Or better yet sample code?