This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, Just wondering what was the design decision behind not having IDisposable on the base Entity class? Thanks, Kavan |
|
|
Hi Kavan, Disposable is not required on Entity as there is nothing to dispose. Cheers, Andrew. |
|
|
Hi Andrew, You are right that Entity is lightweight. But what about derived classes and some of their baggage. Also, Entity does publish events which good keep long refs if not properly desubscribed from? I think, especially in Fat Client development, the notion of a solid edit-save-dispose or edit-view-dispose pattern is vital. I think after work with LS for the past few months the solution may lie in an object manager of sorts. Since it seems that UOF is really for the fetch and puts. And of course when the manager is disposed all entities go too. Just thinking out loud. Thanks again, Kavan |
|
|
Hi Kavan, I usually advise putting an app specific base class between Entity<T> and your concrete model and this would be the place to implement IDisposable if required. I agree with your other comments but everyone has slightly different usage requirements. One approach would be to create your own lightweight facade layer, specific to your application, that mediates data access requests. That way, you can centralize and manage your UOW scoping. I would love to make the Repository API more intuitive as it's an area where people tend to have problems. Of course, the easy way is to simply throw the burden of UOW management on to the user (NHibernate etc.) but, in my experience, this is "too much rope" for a lot of users. Cheers, Andrew. |
|