Jason, thanks for the reply. You had me until "it's a good practice
to build view specific DTOs." Wasn't quite sure what you were talking
about in this paragraph. Could you elaborate or point me to some
resources on the subject?
Also, you mentioned that there is no lazy loading for detached
objects. Can I perform a simple read to populate it, then detach and
have it available? Example: Access User.Roles, then detach.
Most of my objects are just POCOs with getters and setters. Would you
still recommend DTOs in all instances, or only when the object has
embedded domain logic?
Finally, if I were to go the DTO route, when I do this:
user.Name = userDTO.Name;
Does my user object get marked dirty if the Name values are the same?
If so, can it be avoided without doing something like this:
if (user.Name != userDTO.Name)
user.Name = userDTO.Name;
Will be doing plenty of testing tonight. Thanks again Jason. Very
helpful.
On Jan 27, 3:59 pm, Jason Meckley <[email protected]> wrote:
> The problem is you are using the session bound entity outside the
> scope of the session. You need to detach the entity from the current
> session before sending across the wire. When you send the entity back,
> you will need to attach/merge it to the current session. (each request
> should have it's own session). You will need to load any data you need
> on the client before detaching from the session. In other words, once
> you detach there is no lazy loading.
>
> I would consider a different approach though.
> reading data:
> 1. get the domain object
> 2. map the domain object to a DTO (AutoMapper makes this real simple)
> 3. pass the DTO over the wire
> writing data:
> 1. send a DTO from the client to the service
> 2. load the domain object from session
> 3. update domain object
> When utilizing this approach it's good practice to build view speific
> DTOs. So for every read/write form you would have 2 DTOs. One for
> displaying the data and a second for modifying the domain object. This
> approach will lead to a lot of view(read)/command(modify) specific
> DTOs, but it's easier to add/modify individual views because the
> view's Model isn't shared by multiple views. It's also easier to see
> what a view does because the view model will only contain properties
> it needs.
>
> On Jan 27, 4:24 pm, Sam Kimmel <[email protected]> wrote:
>
>
>
> > What are the best practices for using NHibernate in web services (or
> > in any n-tier pattern) where you pass your object out of the scope of
> > the session to the client, have them modify it, then send it back for
> > persistence?
>
> > Simple Example with User object:
>
> > * Client calls service to request existing User.
> > * Service opens session, gets User, returns it to client, closes
> > session
> > * Client modifies User, then sends it to the service to persist the
> > updates
> > * Service opens a session, validates object, persists to database,
> > then closes session
>
> > Some questions...
>
> > 1) If the client sets a property on the User object outside the scope
> > of the session:
> > a) Is it marked as dirty?
> > b) If so, is it marked as dirty if they assign the same value
> > that already existed?
>
> > 2) In the service, what is the best way to obtain the previous state
> > for the User? If I attempt to open another copy of the object I get an
> > error saying that the object already exists in the Session. If I try
> > to use the method outlined here (http://nhforge.org/wikis/howtonh/
> > finding-dirty-properties-in-nhibernate.aspx), I get null errors when
> > attempting to unproxy. The only thing I can think of is to user 2
> > sessions: Get a copy of the original in the first, then check the
> > values in the second. I'm guessing there is a better way or that I am
> > missing something.- Hide quoted text -
>
> - Show quoted text -
--
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.
