I am new to EF4 and are trying to follow the guidance as best I can, so I have choosen to go down the POCO route and have put the POCO classes in there own project. I have added repository classes in the DataAccess project and off course the DataAccess project reference the POCO project.
I am currently adding business functionality to the POCO classes and hit a snag where a particular method on one of the POCO objects creates a bunch of other POCO objects, which is cool. BUT, the POCO objects that it creates are already in the database so know I need my BusinessEntity project to reference the DataAccess project which of course is creating a circular reference.
Any guidance in this space would be much appreciated.
Hopefully I'm not misunderstanding your issue, but it kind of sounds like you may want to go with a DTO (Data Transfer Objects) type route. I am new to EF myself but am currently working on an EF, WCF, WinForms project. I have contract objects for my WCF service that I use to send data back to the client. I map properties from my EF Entities to my DTO objects in my business layer. I use DTOs because my client does not need all the properties of the EF Entity. Try this link. I found some really good stuff regarding project structure. Hope this helps.
Related
Say I have a Visual studio solution with two projects: one web project, and one data project.
Does it really matter whether I pass the EF object from the data project to the web project, or do I need to explicitly define POCOs in the data project to pass to the web project?
It seems to me that needing to create POCOs instead of simply using EF objects adds yet another thing that needs to be done...and I don't particularly see the purpose.
If you're using Entity Framework 4, the EF objects are POCO objects, and so should be used in any situation where your Model matches your EF object (CRUD operations are the typical ones). However there will more than likely be situations whereby the standard POCO object doesn't encapsulate all of the fields that are needed for a View Model (typical ones I have this with are account pages where you have two password fields) and so you will need to create a Model for the page, which then passes the data into your EF POCO objects.
So if you're using DbContext (which creates POCO objects for you) there is no reason not to use those objects.
It's not a good practice to pass the EF objects directly to the web project. As the state changes occurring in the EF objects can directly reflect on the database. Because of this you should explicitly define POC objects for web project.(we can call this as Data Model or simply Model. The POC object used for retrieving data from the View can be called as View Model. In appropriate situations you can use the same POCO class as a Data Model as well a View Model)
I'm starting from a point very similar to: Domain Entities, DTO, and View Models.
The advised use of DTOs to map between the domain model and the MVC's ViewModel seems consistent expectations. I seek details of how to bridge the domain model (Entity Framework-based project) to the WebAPI mvc project.
I'm starting with a project of simple POCOs (generated by EF PowerTools to reverse engineer my existent db) that I want to connect to an MVC4 WebAPI project.
I expect I'll be adding business logic to the baseline POCO project as my solution evolves and perhaps this is the crux of this issue. The business logic that transforms the POCOs into something that can be mapped to the MVC project.
Exactly how do I wire these projects together so i can start creating controllers in the MVC project that knows about the entities of the EF project? Automapper? Can we point to posts/docs where this specific feature of Automapper is employed?
You don't want controllers that knows about the EF entities - that's the whole point of this. :)
You yourself say that the DTOs should be used to map your domain to your view model, and then you ask "how can I bridge my domain model with the mvc controllers?". You've already answered this - with DTOs!
The DTO serves as a transport layer between complex business objects and models used to display a certain view. Both of these have special requirements that don't strictly relate to "just data" - hence using DTOs will give you a greater decoupling and separation of concerns.
If you don't decouple domain from view model, you will be forced to directly reference your EF objects in your view model code, which exposes unnecessary data and functions "up the chain".
Now, if you use WebAPI as a way to ship data then I think you could usually get away with sending the DTOs, since WebAPI data usually wouldn't be implementing view model logic. But YMMV of course, depending on how you plan to use your controllers.
For AutoMapper I'd say it's best to start with their own docs (they even use DTO examples in them): http://github.com/AutoMapper/AutoMapper/wiki/Getting-started
I have an ASP.NET MVC 2 application with a POCO domain model and an NHibernate repository layer. My domain model has no awareness of my viewmodels so I use automapper to go from viewmodel to entity and vice/versa.
When I introduced WCF to my project (a late requirement), I started having to deal with disconnected objects. That is, I retrieve an entity from the database with NHibernate and once that entity is serialized it becomes disconnected and each child collection is loaded regardless of whether or not I plan on using it meaning I'm doing alot of unnecessary database work.
After reading up on this, I see that it is highly recommended that you not expose your entities outside of your domain project and you should instead use DTOs.
I see the reason for this but I'm having trouble figuring out how to implement it.
Do I map from viewmodel to DTO in ASP.NET MVC, send DTOs through the service layer, and map from DTO to entity in the service layer? Where should I define my DTOs?
I like to have my service layer keep entities encapsulated within it, and return/receive only DTOs. I keep the service contracts as well as the DTO's in a separate assembly which both the MVC project and the Service implementation reference.
Inside the service call implementation, the service maps dto's to entities, then does the interaction with repositories and other entities as it needs to.
On the app/mvc project I sometimes will get lazy and just use DTO's as the models for certain actions (especially CRUDy ones). If i need a projection or something like that, then I'll make a viewmodel and convert between DTO and viewmodel with automapper etc.
How exposed your entities are is a subject of much debate. Some people will push them all the way to the view/app layer. I prefer to keep them in the service layer. I find that when the entities leave the service layer, you find yourself doing business logic type stuff anywhere where they're interacted with, stuff that should probably reside in a service.
I treat my DTOs like ViewModels because the UI layer ( MVC app ) is requesting them. You could go Entity -> DTO -> ViewModel but I think thats over engineering if the only consumer of your service is an MVC application. If somehow the DTOs will actually be used for data and not simply screen specifications then you should probably use additional mapping.
I've also simply returned entities from my WCF layer and let the automatically generated proxy objects on the client be the DTO. The entities almost become DTOs because of the proxy classes and no business logic comes over to the client.
And of course, this is all "It Depends" what your architectural goals are. This question is borderline subjective and argumentative IMHO.
I like defining the DTO in the MVC project and then creating extension methods to transform from domain entity to DTO (and vice-versa).
The transformation would take place in the mvc functions.
I just wrote a post about a way of getting around all this DTO <-> DO transformation. Maybe you check it out http://codeblock.engio.net/?p=17
Hi I've been given the task of creating an N-Teir website using the Entity Framework 4 and am coming up against some brick walls, more than likely in my knowledge.
My plan so far was to have these layers
Website (application layer),
What I'm calling Name.Framework (BLL),
Name.Data (DAL),
Name.Entities (contains POCO classes and other struct classes used in website/bll,
Name.Common (utility class)
I've tried to use the repository class, but am struggling to make things work how I thought they would. Below are a few examples of what I'm getting stuck on.
If I want to use .include() would this be in my Repository or is this the responsibilty of the business layer? (and I have no idea how this would work in the BLL)
Same question for .Order()? As I understood it this would need to be in repository or at least passed into the repo in some way?!?
Should I be using the BLL to pass in the Context to the repository/data layer? At the moment when I get an entity from the Data layer any navigation properties that weren't referenced in the repo just come back with 'Object Context Disposed', should the Business layer still hold the context etc so that this wouldn't happen?
Or to summarize this HELP!!!
I need to have this in some sort of order by tomorrow (eek!) as the project leader wants to know if we are going to continue with Entity Framework or move to NHibernate as in-house we have more knowledge of it.
Thanks for any help or suggestions
Matt
Looking for something similar myself I found this. Not looked into it too much at the moment but looks promising.
I'm currently working on a web hobby project with EF4 Code-Only, where I have the following structure ([name] being the name of my project):
[name].Web - An ASP.NET MVC 2 project
[name].Web.Models - Custom view models, along with AutoMapper mappings from my entity objects
[name].Models - My POCO classes, and interfaces for repositories
[name].DataAccess - Some interfaces related to data access, for example IUnitOfWork
[name].DataAccess.EF - All Entity Framework related classes and interfaces
I also have a test project for each of the above, plus a couple of projects with helpers and extensions for the tests.
It might be relevant to mention that part of the purpose of this hobby project is for me to learn how to use EF4 with some design patterns of my own choice (the ones that concern EF in this project are the Repository Pattern and the Unit of Work pattern). Another partial purpose is to build up a code base that I can re-use in later projects, and this has affected the division between projects in my application - for example, if I wasn't concerned with re-use, I'd probably have all data access related classes in one project instead of two.
I've implemented a basic EF, poco, Repository, UnitOfWork architecture largely following this article here:
http://devtalk.dk/CommentView,guid,b5d9cad2-e155-423b-b66f-7ec287c5cb06.aspx
I found it to be very helpful in these endeavors. Don't know if it helps you but others might be interested in the link.
In my first ASP.NET MVC applications, the model was a simple O/R mapping between a table and the classes, managed by the Entity Framework.
Now I would like to add some meat to this skeleton, and introduce business methods for the generated classes. What is the recommended approch to this in ASP.NET MVC (with Entity Framework)? My favorite would be solution which also can be used in a service layer, with no ASP.NET MVC references, so that the same domain logic also could be reused in a desktop client.
Technically, I think it should be possible to extend the generated classes in a way which preserves the additional business logic even if the O/R classes need to be refreshed. (This is more a question related to the Entity Framework however.)
Edit: Many thanks for the contributions, and the information about the next version of Entity Framework (4.0). Building two sets of classes, one auto-generated to represent the data in the persistency layer and one for the actual business logic sounds interesting.
Within MVC.Net, the model is the least clearly defined part. In my opinion, it's basically the rest of your application (i.e. anything not related to the View or the Controller). The O/R Mapping part of your application should probably be outside of the "Model" also, as this is more of a data layer. The Model, should really deal in business objects and create views of your data to pass to the View.
There are lots of differing opinions on this, but I think it's best not to think of MVC.Net as traditional MVC Architecture.
If you are using EF v1.0 right now, the Entity Framework is very intrusive into your application, which means that you cannot create POCO very easily. The way you can extend your model is by using the partial class. So when you refresh your model, the partial class you did will still be valid. The Entity Framework team realizes this is a problem , and have improved this in next version (EF V4.0).
NHibernate is much more friendly and allow you easily extend your business logic.
I really think this blog post by Jeremy D. Miller is very good at pointing out the problem.
Abstract your Business Layer out into another project, then pass an instance of it onto your mvc controller using something like structure map. You can then call this Business Layer from your controller to retrieve your business entities (Model) and pass them on to the UI. This will allow you to resuse your Business Layer in your desktop application.
Not only meat but also some clothes and a style could be added to this project to make it seem chic. It depends on the time you have for the project. If you have time, I could suggest you to get a look to TDD and the frameworks that could be used with TDD such as Castle, NUnit, Moq etc.
As you mentioned a service layer is a must for any project but with these kinds of frameworks you could design your architecture more robust.