Should I use NHibernate Collection Cascading to perform collection save-updates, or should I use repositories to persist entity collection entities ?
It does not usually make sense to enable cascade on a <many-to-one> or <many-to-many> association. Cascade is often useful for <one-to-one> and <one-to-many> associations.
If the child object's lifespan is bounded by the lifespan of the parent object, make it a life cycle object by specifying cascade="all-delete-orphan".
Otherwise, you might not need cascade at all. But if you think that you will often be working with the parent and children together in the same transaction, and you want to save yourself some typing, consider using cascade="persist,merge,save-update".
Better look at code generator tools like My Generation,CodeSmith for NHibernate template.If you want to use My Generation then take a look at http://www.mygenerationsoftware.com/TemplateLibrary/User/?guid=06437130-d390-4145-8e86-ed9682ff444b template.Really good.
Related
In order to make sure that all child elements are deleted, I am currently having to do this:
ComponentType type = db.ComponentTypes.First(t => t.ID == Convert.ToInt32(button.CommandArgument));
db.RigActions.DeleteAllOnSubmit(type.Components.SelectMany(c => c.RigActions));
db.Components.DeleteAllOnSubmit(type.Components);
db.ComponentTypes.DeleteOnSubmit(type);
db.SubmitChanges();
For maintainability purposes, this is scaring me that I (or another developer) might overlook all of the cleanup necessary when a parent (or in this case - a parent of a parent) element is deleted.
Does Linq have any type of dependency property I can set so that when a Component type is deleted, it deletes all component records, and all actions belonging to each component record?
I'm not sure it can be done in Linq (it probably can). It would be far easier if you defined a CASCADE DELETE on your database though. That way, child records would be deleted automatically and you'd not need to worry about forgetting anything.
This article might give you a bit more information
http://www.mssqltips.com/sqlservertip/2743/using-delete-cascade-option-for-foreign-keys/
This article is about setting up cascade delete within EF
Entity Framework on delete cascade
I need something like "AllDeleteOrphan" but instead of deletion it must change parent of all orphan entities to a special entity that represent "not specified" state.
I'm not sure there are any built in functionality that supports this.
What you could probably do is create an interceptor and add custom logic into the OnDelete method to do what you need.
Some articles that touches on your point:
http://weblogs.asp.net/ricardoperes/archive/2013/03/21/soft-deletes-with-nhibernate.aspx
http://candland.net/2010/01/09/intercepting-nhibernate-to-handle-additional-database-work/
I am using NHibernate to persist my entities in the database. MY entities have some relationships between them resulting into some mapped collections. I my case I use the Iesi.ISet interface to map these collections. I was wondering if it's possible for nhibernate to check if the properties containing those collections to be automatically set when I execute save if they are null.
This is how it should work. I have a property with a collection called "MyCollection" that is null before I save it to the database. I want NHibernate to set a collection to that property so that it's not null anymore on save. Is this possible?
This is what your constructors are for.
If you very much want to hide such initialization behind NHibernate you might be able to inject the code for this using an NHibernate interceptor or event listener.
Is it possible to pass a reference at load time of a parent to it's children without a relationship back to the parent from the child?
I would prefer to NOT have a mapped property for this purpose (i.e. prefer not to use bi-directional relationships for this purpose).
You could probably do it with a linking table but you'd have to enforce one-to-many via code otherwise it could easily become a many-to-many. The jist of the linking table would be that it keeps the association between the parent and its children, rather than the child object itself.
I wasn’t sure how to really word my question and I may change it based on some feedback.
When it is a good idea to have reference relationships (in my POCOs) setup so I can look up a parent record from a child or the reverse? Is it good practice to always have a way to “reverse” lookup an item or collection of items? I know it greatly depends on my application, but I just want to make sure of this before I start molding my application.
So, let’s say I have two tables: States and Countries. States has a relationship with countries (many-to-one) and vice-versa (one-to- many). My class for state would have a property for Country and my Country class would a property for a collection of states. This is pretty standard.
In that example it may make sense to allow a country to lookup the associated states. Can someone think of a time where I may not care about that association so I don’t have the overhead of loading the items for a collection or a single item?
It is more about design decission of your entities. If you are using code first you always need a navigation property on at least one side to create relation in the database. You can start with a simple approach and define property on a side where it make sense and add it to other side only if you need it somewhere.
There are situations where you know that you will never work with child entity without its parent (it leads to theory about aggregation roots whre child entity can't exist without its parent). In such case child doesn't need to have navigation property to parent.
In your scenario do you expect to work with State without Country which it belongs to? If yes it is probable that you would like to know which States a Country contains but in the same time you would probably would like to know which Country a State belongs to so defining navigation property on both sides make sense.