This can be ok or it can be really bad. The problem with this architecture is that when you just send UP DTOs to the server and let the server try to figure out what has changed you lose any context of the behavior associated with the change on the client (this also shows that you have no behavior within your domain model). Often times the context of why the data is changing is important and you will be unable to maintain this information....
In other words ... you will know that field x changed ... but often there are multiple ways field x can change and you will have no idea which of those you were on. Cheers, Greg On Mon, Feb 2, 2009 at 11:47 AM, Caio Kinzel Filho <[email protected]> wrote: > > Hi, > > Thank you all for the ideas. Reading it I could think of the following: > > Service layer: > - References NHibernate, FluentNHibernate > - Implement DTO objects > - Mapping for the nhibernate > - Repository service, something like > > { > T Get<T>(...) where T : ServiceLayer.DTO > > void Save<T>(T objToSave) where T : ServiceLayer.DTO > > //and Query, Delete, etc > } > > Application layer (web, smart client, whatever) > - References ServiceLayer only > - Entities are the ServiceLayer.DTOs > - Uses the Repository service from ServiceLayer to persist entities > - Uses InMemoryRepository in unit tests > > Maybe I could put the Repository direct in the Application layer, and > pass it the NH sessions by the Service layer. > > Other than that, I'm thinking of how to work with lazy loading with > this approach. > > What do you all think about that? Any better idea? > > Thanks, > Caio > > On Mon, Feb 2, 2009 at 1:16 PM, Tim Scott <[email protected]> > wrote: >> >> I created an NHibernate app that uses WCF for remoting -- sending >> domain objects across the wire to a Windows "smart client." There's a >> trick you need to know to do this. I wrote about it here: >> http://lunaverse.wordpress.com/2007/05/09/remoting-using-wcf-and-nhibernate/ >> >> This may have changed with newer versions of WCF and NHibernate. That >> said, I don't recommend this approach. Aside from the well known >> arguments for SOA, you have the practical problem of lazy loading, as >> has been mentioned. If I were starting this over, I would use a DTO >> approach. >> >> On Feb 1, 10:57 am, Frederic <[email protected]> wrote: >>> John Rayner a écrit : >>> >>> > If your domain aggregates are reasonably well-defined, you can keep >>> > track of the size of the WCF payload. Personally, I have no big >>> > problem giving read-only access directly onto entities, although I >>> > shudder at the thought of taking update messages in this fashion (i.e. >>> > simply persisting a desrialized object). My project exposes entities >>> > from read access and uses separate command objects for insert / update >>> > actions. >>> >>> > OTOH exposing domain objects doesn't give you the ability to have >>> > multiple "views" of the same object, e.g. a small class containing >>> > basic person details, and a larger class containing their full >>> > profile. Using entities + DTOs means that you can use the same entity >>> > and map onto a different DTO for serialization. Exposing entities >>> > directly means that you need to create multiple entity classes (e.g. >>> > PersonSummary and Person). This can feel a little bit odd, but IMO >>> > it's manageable. I imagine that DDD purists would tell me that this >>> > is just wrong! :-) >>> >>> > Cheers, >>> > John >>> >>> > On Jan 30, 8:03 pm, Eric Hauser <[email protected]> wrote: >>> >>> >> The biggest pitfall to consider is how much data will be serialized >>> >> when you expose your entities over WCF. For instance, you can map a >>> >> collection that may be very large on an object and if you are not lazy >>> >> loading, all of that data will be serialized over the web service. >>> >>> >> The answer really is "it depends", but assuming this is an large >>> >> project, I always consider my web service contracts to be data >>> >> transfer objects. Explicitly copy the data from the entities onto the >>> >> contract. It is best to think of web service objects as messages and >>> >> not entities. There should be a decent amount of information on this >>> >> subject if you do some searching. >>> >>> I quite agree with you. You can take advantage using DTO. >>> >>> One of the top advantage, is that with do not have a strong correlation >>> between persistence and business. >>> Most of the developper appreciate this separation of concerns, and it >>> gives us more control over the database. >>> >>> And the same way, you can re-use entities, stop thinking in terms of >>> database. >>> >>> DTO are not that bad. >>> >>> fred >> >> > >> > > > > -- It is the mark of an educated mind to be able to entertain a thought without accepting it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
