 |
|
| .NET DotNet Forum Index » Visual C# Forum » Architectural issues with Entity Framework... |
|
Page 1 of 1 |
|
| Author |
Message |
| Oscar Thornell... |
 Posted: Tue Oct 27, 2009 5:10 am |
|
|
|
Guest
|
Hi,
I am having serious trouble designing/architecting a viable solution for an
ASP.NET application and EF.
My main concern is changetracking and the lifecycle of the ObjectContext.
Ench problems with the stateless nature of a web application /ASP.NET page
life cycle. In my view change tracking in EF 1.0 is seriously broken for any
type of server oriented application (request/response pattern) involving
more than one entity at a time i.e. objectgraphs. If you wanted that kind of
solution you would have to code it manually.
Exploding/recombining/serializing the graph yourself, and with a decent
domain that would sum up to a ridiculous amount of code. After 2 months of
nearly gotten everything to work with quality the last time I pulled the
plug and went for NHibernate.
...and now once more I am standing in front of the same dilemma. The
technical requirement is simple: a layered ASP.NET application that uses EF.
I am free to start using VS.NET 2010 beta 2 and the EF 4.0 framework. The
POCO/T4 support in EF 4.0 is a good start and gives us the possibilities of
a separation for the model in a more DDD centric approach. But what about
change tracking for object graphs in a dettached/attached mode? Has EF 4
given us anything in this area? Or do we still need to wrap each entity in
the model in an ObjectProvider pattern and handle every entity separately in
the ASP.NET client?
Does it exsist a best practice from Microsoft (or anywhere else)? If so
please share a link...
Have some of you brilliant techies solved this? Am I missing something? :-(
Regards
Oscar Thornell
P.S Pleaes excuse the cross posting... D.S |
|
|
| Back to top |
|
|
|
| Gregory A. Beamer... |
| Posted: Tue Oct 27, 2009 8:25 am |
|
|
|
Guest
|
"Oscar Thornell" <oscar.thornell at (no spam) hotmail.com> wrote in
news:BB0E6160-50BA-415B-A160-BACE7B7A1EEB at (no spam) microsoft.com:
Quote: In my view change tracking in EF
1.0 is seriously broken for any type of server oriented application
(request/response pattern) involving more than one entity at a time
i.e. objectgraphs.
Agree whole heartedly. It is also a bad model, until POCO support, for SOA
implementation that cross platform boundaries.
Quote: ..and now once more I am standing in front of the same dilemma. The
technical requirement is simple: a layered ASP.NET application that
uses EF. I am free to start using VS.NET 2010 beta 2 and the EF 4.0
framework. The POCO/T4 support in EF 4.0 is a good start and gives us
the possibilities of a separation for the model in a more DDD centric
approach. But what about change tracking for object graphs in a
dettached/attached mode? Has EF 4 given us anything in this area? Or
do we still need to wrap each entity in the model in an ObjectProvider
pattern and handle every entity separately in the ASP.NET client?
Does it exsist a best practice from Microsoft (or anywhere else)? If
so please share a link...
Check out this Developmentor article:
http://www.develop.com/entityframework4
It is a good entry and deals with the T4 templates and how you
ApplyChanges. I have not played through the whole scenario you have here,
so I cannot state fully whether or not EF 4 soles everything or not.
Peace and Grace,
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
Twitter: at (no spam) gbworld
Blog: http://gregorybeamer.spaces.live.com
*******************************************
| Think outside the box! |
******************************************* |
|
|
| Back to top |
|
|
|
| Mr. Arnold... |
| Posted: Tue Oct 27, 2009 12:20 pm |
|
|
|
Guest
|
Oscar Thornell wrote:
Quote: Hi,
I am having serious trouble designing/architecting a viable solution for
an ASP.NET application and EF.
My main concern is changetracking and the lifecycle of the
ObjectContext. Ench problems with the stateless nature of a web
application /ASP.NET page life cycle. In my view change tracking in EF
1.0 is seriously broken for any type of server oriented application
(request/response pattern) involving more than one entity at a time i.e.
objectgraphs. If you wanted that kind of solution you would have to code
it manually. Exploding/recombining/serializing the graph yourself, and
with a decent domain that would sum up to a ridiculous amount of code.
After 2 months of nearly gotten everything to work with quality the last
time I pulled the plug and went for NHibernate.
Well, I use the EF on the backend of WCF Web Service solutions with
Model View Presenter pattern. The thing is that an ADO.Net Entity
Framework entity is an implicit serialized Data Contract to WCF.
Therefore, WCF is going to take care of the serialization of the object
graph by itself on the client and the server sides. This also means that
I can change the entity on the side if I choose to and sent it back to
the server side and persist the change to the database.
Quote:
..and now once more I am standing in front of the same dilemma. The
technical requirement is simple: a layered ASP.NET application that uses
EF.
Yeah, UI/Model View Presenter/BLL/WCF Web service/DAL/EF Model is no
problem at all. But the key here is to use marked serializable Data
Contract DTO(s) Data Transfer Objects that keep their state all the way
up to the UI and all the way back down to the DAL/Model. It's the DTO
with its state information and using the DAL that tells the DAL what
persist path the object is to take with its associated Entity object.
Quote: I am free to start using VS.NET 2010 beta 2 and the EF 4.0
framework. The POCO/T4 support in EF 4.0 is a good start and gives us
the possibilities of a separation for the model in a more DDD centric
approach. But what about change tracking for object graphs in a
dettached/attached mode? Has EF 4 given us anything in this area? Or do
we still need to wrap each entity in the model in an ObjectProvider
pattern and handle every entity separately in the ASP.NET client?
About the only time I actually bring a entity intact to the DDD is when
I need the entity in a read only capacity, because information in the
entity that's used in a decision making process on the domain model.
Quote:
Does it exsist a best practice from Microsoft (or anywhere else)? If so
please share a link...
Have some of you brilliant techies solved this? Am I missing something? :-(
The one thing I have found with the EF Model and the designer is that
association between entities must be removed, the underlying database
table associations are still there but off the model, and you do not
check mark select multiple tables at one time to be placed on the model.
You select the entries to be on the model one at a time. You reverse
order the selection and all child entities must be on the model first
before its parent.
I mean you to to the edmx, delete the association set tag and all its
data, save it, comeback to the EF designer for the model delete all
association line lines and validate the model.
You do that and you have complete control of the model. |
|
|
| Back to top |
|
|
|
|
|
All times are GMT - 5 Hours
The time now is Mon Mar 22, 2010 10:58 am
|
|