we are currently using EF 4.1 and are thinking about a new alternative for our object model which is terrible. We do have POCOs in a sort of BL-Layer and above a GUI-Model with Objects wrapping the POCOs to offer BindingLists to the UI instead of the BL's IEnumerables.
We thought about deriving the UI-Model from the 开发者_如何学CPOCOs but I have no Idea how this would work with the EF instantiating the objects as it shouldn't know anything about the UI objects. Is there some way to move the instantiating process to factories or does anyone have an idea how to promote the object afterwards from base to derived type (which isn't really a good idea at all, is it?)
Any help, suggestions or comments would be highly appreciated.
Best regards Gope
No it is not possible to move object instantiation to factories. Because of that deriving custom classes from your entities will not work because EF will not create those instances for you and you will also not be able to persist those instances because EF will not know how to map them.
The introduction of POCO support in EF4 was to allow the business objects to exist without extending objects in the EF (specifically EntityObject). I've worked on a number of systems now where the domain model is shared across all layers in the system and a repository patterns is used to handle object persistence. A number of teams use the concept of data transfer objects (DTO) to provide the UI with a lightweight object that the UI can work with (which also provides a certain degree of abstraction to the BLL from the UI).
Microsoft Spain recently published a document and sample application that talks about how to structure enterprise applications (http://microsoftnlayerapp.codeplex.com/) which might give you some ideas about how to structure things better.
精彩评论