NHibernate is meant to manage the Object-Relational interface between your
Domain Model and your persistence layer (RDBMS).

It is not used to manage the ViewModel interface with the Domain Model. Any
functionality that seems to support this interface is incidental and as you
are finding will not work the way you are hoping. There are samples where
the ViewModel and the Domain Model are identical, and I wish these samples
had never been created, because they only work correctly because of the
simplicity of the Domain Model, and everything falls apart when a more
complex Domain Model and ViewModel are attempted.

I would seriously recommend you rethink your architecture. NHibernate is not
a panacea for poor design.

John Davidson

On Thu, Oct 28, 2010 at 11:43 AM, cremor <cre...@gmx.net> wrote:

> I am using ViewModel objects for the binding to my screens. But my
> ViewModel objects must write the data to the domain (NHibernate)
> objects, how would I use the business logic otherwise?
> Also, if I only write the data to the domain objects on save, I'd have
> to implement change tracking myself. NHibernate already implements
> change tracking, so why not use it?
>
> On 28 Okt., 17:28, John Davidson <jwdavid...@gmail.com> wrote:
> > This is the reason for using a DTO rather than the NHibernate object. The
> > DTO data is only moved to the NHibernate object after the user has
> pressed
> > save. Screen objects should not be NHibernate objects.
> >
> > John Davidson
> >
> > On Thu, Oct 28, 2010 at 9:31 AM, cremor <cre...@gmx.net> wrote:
> > > Just for curiosity I switched my ID generator from Sequence to
> > > SeqHiLo. Calling session.IsDirty() now doesn't execute a select
> > > statement for the ID anymore (which is expected with SeqHiLo), but it
> > > still queues the insert statement.
> > > Then I even implemented my own IIdentifierGenerator which just returns
> > > an increasing number in Generate(), and IsDirty() STILL queues the
> > > wrong insert statement!
> >
> > > What's the reason for this?
> >
> > > I highly doubt that this behaviour is as designed. Because, in
> > > addition to the problem with not null or check constraints and the
> > > inconsistent behaviour I explained in my first post, this even results
> > > in the following behaviour, that is clearly a bug in NHibernate in my
> > > opinion (please tell me if I'm wrong):
> >
> > > Use-case:
> > > 1. Persistent Parent is loaded.
> > > 2. A new Child is added to the collection.
> > > 3. session.IsDirty() is called (UI checks, if it should enable the
> > > save button).
> > > 4. NHibernate queues an insert statement for the Child using its
> > > current (default) values.
> > > 5. User deletes the just created Child again (it is removed from the
> > > collection in the Parent).
> > > 6. User saves the changes, session.Flush() is called.
> >
> > > Now NHibernate does the following:
> > > 1. The queued insert statement for the new Child is executed (let's
> > > ignore the not null constraint for now).
> > > 2. Parent version column is updated.
> > > 3. The child (which shouldn't be in the DB) is commited. The next load
> > > of the Parent will return the Child which shouldn't be there.
> >
> > > I'd really appreciate any advice on this topic - or a NHibernate
> > > bugfix ;-)
> >
> > > On 7 Okt., 15:49, John Davidson <jwdavid...@gmail.com> wrote:
> > > > You probably need to do an id check yourself first, before the
> IsDirty.
> >
> > > > John Davidson
> >
> > > > On Thu, Oct 7, 2010 at 7:32 AM, cremor <cre...@gmx.net> wrote:
> > > > > Sadly, a different ID generator is no option for me. My application
> is
> > > > > not the only one accessing the DB and the other systems rely on
> these
> > > > > sequences.
> >
> > > > > What is the reason for getting an ID and flushing the Child when
> > > > > checking IsDirty()? Shouldn't it be enough for NHibernate that the
> ID
> > > > > of the Child has an unsaved-value?
> >
> > > > > On 7 Okt., 12:56, John Davidson <jwdavid...@gmail.com> wrote:
> > > > > > The use of sequence is similar to identity in that the db
> generates
> > > the
> > > > > id
> > > > > > stored rather than the other id generators which create the id
> within
> > > > > > NHibernate. For your problem the issue identified in jira NH-2136
> is
> > > the
> > > > > > same.
> >
> > > > > > The solution is to use an NHibernate created id from hi-lo or
> guid
> > > based
> > > > > > generators.
> >
> > > > > > John Davidson
> >
> > > > > > On Thu, Oct 7, 2010 at 4:09 AM, cremor <cre...@gmx.net> wrote:
> > > > > > > I currently have the problem that NHibernate creates an insert
> > > > > > > statement for new items in a collection of a persistent entity
> when
> > > > > > > calling session.IsDirty().
> >
> > > > > > > My configuration:
> > > > > > > * NHibernate 3.0.0.Alpha3
> > > > > > > * An entity "Parent" with a collection of "Child" entities.
> One-to-
> > > > > > > many side is mapped as set, inverse, lazy and cascade
> all-delete-
> > > > > > > orphan. Many-to-one side is mapped as lazy.
> > > > > > > * All IDs are using the sequence generator.
> > > > > > > * Optimistic lock is by version column.
> > > > > > > * Session.FlushMode is Never.
> >
> > > > > > > My use-case:
> > > > > > > 1. Persistent Parent (already containing some Child entities)
> is
> > > > > > > loaded.
> > > > > > > 2. A new Child is added to the collection.
> > > > > > > 3. session.IsDirty() is called (UI checks, if it should enable
> the
> > > > > > > save button).
> > > > > > > 4. NHibernate executes a select statement for the ID of the new
> > > Child
> > > > > > > and queues an insert statement for the Child using its current
> > > > > > > (default) values. (Problem starts here: Why is it needed to get
> the
> > > ID
> > > > > > > of the new Child and queue an insert statement?)
> > > > > > > 4a. (Optional step) Some more new Childs are added. No more
> select
> > > > > > > statements are executed or insert statements are queued when
> > > calling
> > > > > > > session.IsDirty() because IsDirty() returns early because it
> knows
> > > it
> > > > > > > already has queued statements (very inconsistent behaviour in
> my
> > > > > > > opinion!)
> > > > > > > 5. User has to change a property of the Child to get rid of UI
> > > > > > > validation errors (a property is not allowed to be empty, but
> is by
> > > > > > > default to force the user to input something meaningful).
> > > > > > > 6. User saves the changes, session.Flush() is called.
> >
> > > > > > > Now NHibernate does the following:
> > > > > > > 1. Select statements for the new IDs of additional Childs from
> step
> > > 4a
> > > > > > > are executed.
> > > > > > > 2. The queued insert statement for the first new Child is
> executed.
> > > > > > > This statement uses the default values of the class and fails
> with
> > > an
> > > > > > > not null constraint error.
> > > > > > > 3. (If I disable the not null check in the DB) Parent version
> > > column
> > > > > > > is updated.
> > > > > > > 4. Additional childs from step 4a are inserted (with the
> already
> > > > > > > changed properties, so these statements are ok).
> > > > > > > 5. The first new Child is updated with the changed property.
> >
> > > > > > > I found the following Jira issue which already describes the
> > > problem,
> > > > > > > but it was rejected because it's "Expected behavior using
> > > identity":
> > > > > > >http://216.121.112.228/browse/NH-2136
> > > > > > > But I'm using sequence, not identity, and still have the same
> > > problem.
> >
> > > > > > > Does anyone know if this is a bug at my side, a bug in
> NHibernate
> > > or
> > > > > > > just "by design" like for identiy IDs?
> >
> > > > > > > --
> > > > > > > You received this message because you are subscribed to the
> Google
> > > > > Groups
> > > > > > > "nhusers" group.
> > > > > > > To post to this group, send email to nhus...@googlegroups.com.
> > > > > > > To unsubscribe from this group, send email to
> > > > > > > nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com>
> <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com>
> >
> > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com>
> <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com>
> >
> >
> > > > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com>
> <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com>
> >
> > > <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com>
> <nhusers%25252bunsubscr...@googlegroups.com<nhusers%2525252bunsubscr...@googlegroups.com>
> >
> >
> > > > > > > .
> > > > > > > For more options, visit this group at
> > > > > > >http://groups.google.com/group/nhusers?hl=en.
> >
> > > > > --
> > > > > You received this message because you are subscribed to the Google
> > > Groups
> > > > > "nhusers" group.
> > > > > To post to this group, send email to nhus...@googlegroups.com.
> > > > > To unsubscribe from this group, send email to
> > > > > nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com>
> <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com>
> >
> > > <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com>
> <nhusers%252bunsubscr...@googlegroups.com<nhusers%25252bunsubscr...@googlegroups.com>
> >
> >
> > > > > .
> > > > > For more options, visit this group at
> > > > >http://groups.google.com/group/nhusers?hl=en.
> >
> > > --
> > > You received this message because you are subscribed to the Google
> Groups
> > > "nhusers" group.
> > > To post to this group, send email to nhus...@googlegroups.com.
> > > To unsubscribe from this group, send email to
> > > nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com>
> <nhusers%2bunsubscr...@googlegroups.com<nhusers%252bunsubscr...@googlegroups.com>
> >
> > > .
> > > For more options, visit this group at
> > >http://groups.google.com/group/nhusers?hl=en.
> >
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "nhusers" group.
> To post to this group, send email to nhus...@googlegroups.com.
> To unsubscribe from this group, send email to
> nhusers+unsubscr...@googlegroups.com<nhusers%2bunsubscr...@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/nhusers?hl=en.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"nhusers" group.
To post to this group, send email to nhus...@googlegroups.com.
To unsubscribe from this group, send email to 
nhusers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/nhusers?hl=en.

Reply via email to