Beginners question: How to add or delete related entity

[Skiv]

For example, I have entity with one to many relation: Department has
many Units:

class Department
{
public decimal Id{get;set;}
public IList<Unit> Units{get;set;}
}

class Unit
{
public decimal Id{get;set;}
public Department {get;set;}//Parent
}

If I want add new Unit:
Unit newUnit =new Unit{Department=someDepartment};
session.Save(newUnit);

So, if I already have parent Department, it's Units collection isn't
updated automatically, I must add it manually:
someDepartment.Units.Add(newUnit);

Same is with entity deletion:
Unit deletedUnit = someDepartment.Units[0];
session.Delete(deletedUnit);
deletedUnit.Department.Units.Delete(deletedUnit);

Is this ok? Maybe there is more convenient way to do this?

[Roger Kratz]

Don't expose the mutable collection. Instead have something like...

department.AddUnit(new Unit());
department.RemoveUnit(someUnit);

...and handle the birefs inside these methods.

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

[Fabio Maulo]

Roger...

Perhaps we should implements a custom ParentChildSet and ParentChildBag somewhere ?

What do you think ?

--
Fabio Maulo

[Roger Kratz]

Personally I don’t think so. What about PI for transient entities? I think this should be a domain concern.

 

Or am I missing how you think this should be solved on newly created entities?

 

/Roger

[Fabio Maulo]

PI ?

[Fabio Maulo]

To try to be a little more clear (and try to use this group even for ideas, not only for NH-Core)...

What is completely possible, without touch NH core, is:

To avoid the implementation of specific methods to Add/Remove children from a collection of Parent-Child relation we can provide "the final cut": strongly typed safe an encapsulated collection to manage Parent-Child relationship.

A little project with those classes with reference only to .NET.

Another project with IUserCollectionType to work with NH.

In this way the user can expose ICollection<TChild> instead IEnumerable<TChild>.

public Order()

{

     Items= new ParentChildBag<Order, OrderItem>(this);

}

public ICollection<OrderItem> Items {get; private set;}

In the other prj we will have PersistentParentChild<TParent, TChild> with the implementation for NH.

With XML mapping you know that the work is easy.

With FNH you can do the same as in XML or with a convetion.

With ConfORM I can implements a simple pattern.

Perhaps we can avoid a hundred of questions about Parent-Child relationship issues giving a cooked and strongly-typed/generic solution for new users ;)

[Roger Kratz]

Ah! You didn't mean to put this collection in NH Core? Sounds just fine.

Thought you meant to to put this collection in core. What I meant with the "PI" was persistance ignorance if this was a NH Core collection needed to be instantiated in domain on transient entities.

________________________________
Från: nhu...@googlegroups.com [nhu...@googlegroups.com] för Fabio Maulo [fabio...@gmail.com]
Skickat: den 3 juni 2010 17:44
Till: nhu...@googlegroups.com
Ämne: Re: [nhusers] Beginners question: How to add or delete related entity

To try to be a little more clear (and try to use this group even for ideas, not only for NH-Core)...
What is completely possible, without touch NH core, is:
To avoid the implementation of specific methods to Add/Remove children from a collection of Parent-Child relation we can provide "the final cut": strongly typed safe an encapsulated collection to manage Parent-Child relationship.
A little project with those classes with reference only to .NET.
Another project with IUserCollectionType to work with NH.

In this way the user can expose ICollection<TChild> instead IEnumerable<TChild>.

public Order()
{
Items= new ParentChildBag<Order, OrderItem>(this);
}

public ICollection<OrderItem> Items {get; private set;}

In the other prj we will have PersistentParentChild<TParent, TChild> with the implementation for NH.

With XML mapping you know that the work is easy.
With FNH you can do the same as in XML or with a convetion.
With ConfORM I can implements a simple pattern.

Perhaps we can avoid a hundred of questions about Parent-Child relationship issues giving a cooked and strongly-typed/generic solution for new users ;)

On Thu, Jun 3, 2010 at 10:57 AM, Roger Kratz <Roger...@teleopti.com<mailto:Roger...@teleopti.com>> wrote:
Personally I don’t think so. What about PI for transient entities? I think this should be a domain concern.

Or am I missing how you think this should be solved on newly created entities?

/Roger

From: nhu...@googlegroups.com<mailto:nhu...@googlegroups.com> [mailto:nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>] On Behalf Of Fabio Maulo
Sent: den 3 juni 2010 14:19
To: nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>
Subject: Re: [nhusers] Beginners question: How to add or delete related entity

Roger...
Perhaps we should implements a custom ParentChildSet and ParentChildBag somewhere ?
What do you think ?

department.AddUnit(new Unit());
department.RemoveUnit(someUnit);

To post to this group, send email to nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com<mailto:nhusers%2Bunsu...@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 nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com<mailto:nhusers%2Bunsu...@googlegroups.com>.

For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

--
Fabio Maulo
--
You received this message because you are subscribed to the Google Groups "nhusers" group.

To post to this group, send email to nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com<mailto:nhusers%2Bunsu...@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 nhu...@googlegroups.com<mailto:nhu...@googlegroups.com>.
To unsubscribe from this group, send email to nhusers+u...@googlegroups.com<mailto:nhusers%2Bunsu...@googlegroups.com>.

[José F. Romaniello]

what about something like this:

new ParentChildBag<Order, OrderItem>(this, oi => oi.Order = this, oi => oi.Order = null);

I write something about this with (INotifyCollectionChanged) some time ago, but i didn't find it useful for nothing

http://jfromaniello.blogspot.com/2009/07/inotifycollectionchanged-one-step.html

2010/6/3 Fabio Maulo <fabio...@gmail.com>

[Fabio Maulo]

On Thu, Jun 3, 2010 at 5:24 PM, Roger Kratz <Roger...@teleopti.com> wrote:

Ah! You didn't mean to put this collection in NH Core? Sounds just fine.

Thought you meant to to put this collection in core. What I meant with the "PI" was persistance ignorance if this was a NH Core collection needed to be instantiated in domain on transient entities.

LOL!!

I'm a "uncoupled" fanatic ;)

even NHibernate is just one of actual options.

--
Fabio Maulo

[Skiv]

So there is no automatic way to handle this problem...

Thanks for the help.

[Fabio Maulo]

in software everything is "automatic" after write some code and compile it in binary

For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.

--
Fabio Maulo

[Diego Mijelshon]

Well, that's not true. I once wrote a program where the user had to do half of the work. But he got paid for that, so he was fine.

   Diego

[Skiv]

This answer can be start of philosophic discussion (flame).
For example, nhibernate supports cascade=All, which will provide
feature on delete to delete also all associated objects. So its
"automatic", because somebody written some code and compiled it, but
everyone else can now enjoy "automatic" nature of associated object
deletion. And then "coding and compiling" can become to simple setting
some config value or following some rules.

> > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .

> > > For more options, visit this group athttp://
> > 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 nhu...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > nhusers+u...@googlegroups.com<nhusers%2Bunsu...@googlegroups.com>
> > .