Thats one way of doing things but in particular to what I was refering to about losing the "context" of behaviors due to DTOs it would simply be to use event sourcing http://martinfowler.com/eaaDev/EventSourcing.html as opposed to bi-directional DTOs.
Cheers, Greg On Mon, Feb 2, 2009 at 2:34 PM, Caio Kinzel Filho <[email protected]> wrote: > > Hi, > > I think that what you are talking about is the same as in > http://www.infoq.com/interviews/greg-young-ddd = "Greg Young Discusses > State Transitions in Domain-Driven Design and DDD Best Practices" > > So if I understand, in the approach I've suggested before, I would > need to, instead of the repository (in the service layer) being > accessible to the application layer, create a set of 'behaviour > methods' to change the state of my data in the data store, and create > a set of 'get methods' to return my DTOs (mapped directly to the data > store) as needed in the application layer. Is that correct? Or what do > you suggest? > > Thanks, > Caio > > On Mon, Feb 2, 2009 at 3:52 PM, Greg Young <[email protected]> wrote: >> >> 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. >> >> > >> > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
