Modeling one to zero or one relationships (Z cardinality) - nhibernate

Question

I'm struggling to find the best way to model 1 : 0,1 relationships ("may have one" or "has at most one"). I believe this is called Z cardinality.
For example, suppose I have two classes Widget and WidgetTest. Not all Widgets are tested and the test is destructive so there can be at most one WidgetTest per Widget. Also assume that it's inappropriate to add the WidgetTest fields to Widget.
I would like my public interface to be:
Widget
WidgetTest { get; set; }
WidgetTest
Widget { get; }
Model 1: Widget has a WidgetTest property and in the database the Widget table has a uniquely constrained foreign key to WidgetTest. My DBA argues that this would allow a WidgetTest record to exist without a Widget.
WidgetTable
WidgetTestId (FK, UQ)
Model 2: Widget has a private collection of WidgetTest and enforces the 0,1 relationship by adding or removing a single object from the collection controlled by a public WidgetTest property. The database models this as 1:m with WidgetTest having a uniquely constrained foreign key to Widget. I argue that this means adopting the model to fit the database schema (i.e. more work for me).
WidgetTestTable
WidgetId (FK, UQ)
Which model is better? Which is easier to achieve with NHibernate? Or is there a third way?
Edit ... Here's what I ended up with:
public class Widget
{
// This is mapped in NH using a access strategy
private IList<WidgetTest> _widgetTests = new List<WidgetTest>(1);
public WidgetTest
{
get { return _widgetTests.FirstOrDefault(); }
set
{
_widgetTests.Clear();
if (value != null)
{
_widgetTests.Add(value);
}
}
}
}

Answer 1

My approach has been to model a one-to-many relationship in the mappings, but to constrain the "many" to a single item. This allows the optional one-to-one, and also guarantees that your WidgetTest instance is persisted when you save the Widget. For example:
public class Widget
{
/// <summary>
/// This property is ignored by the NHibernate mappings.
/// </summary>
public virtual WidgetTest WidgetTest { get; set; }
/// <summary>
/// For easier persistence with NHibernate, this property repackages the
/// WidgetTest property as a list containing a single item. If an
/// attempt is made to set this property to a list containing more than
/// one item, an exception will be thrown. But why bother? Just use the
/// WidgetTest property.
/// </summary>
public virtual IList<WidgetTest> WidgetTests
{
get
{
IList<WidgetTest> widgetTests = new List<WidgetTest>();
if (this.WidgetTest != null)
{
widgetTests.Add(this.WidgetTest);
}
return widgetTests;
}
set
{
if (value != null && value.Count > 1)
{
throw new Exception("The WidgetTests collection may not contain more than one item.");
}
else if (value != null && value.Count == 1)
{
this.WidgetTest = value[0];
}
else
{
this.WidgetTest = null;
}
}
}
}

Answer 2

When you say "assume that it's inappropriate to add the WidgetTest fields to Widget", do you mean in your domain objects or in the database. If you are happy for the fields to be in the same table in the database, how about mapping WidgetTest as a component of Widget? Have the NHibernate mapping file look like:
<class name="Widget" table="Widget">
...
<property name="WidgetProperty"/>
...
<component name="WidgetTest" class="WidgetTest">
<property name="WidgetTestProperty"/>
</component>
</class>
Giving the table structure:
WidgetTable
WidgetProperty
WidgetTestProperty
Which would still let you have the public interface you've specified, however, WidgetTest would become a value object which you may or may not want.

Answer 3

i have 2 other ideas here
Join table and map as Component
ignore Id of dependant class

Answer 4

The answer given by nw. can result in the exception "A collection with cascade=”all-delete-orphan” was no longer referenced by the owning entity instance".
You will find this to be the case if you're using inverse="true" and cascade="all-delete-orphan" in your mapping file.
This is because nw.'s answer creates a new list every time the get accessor is called and doesn't do anything with the list passed in through the set accessor. As such, NHibernate doesn't have the IList<WidgetTest> reference it originally passed in when creating the object and can't proceed with the cascade.
So in order to fix this, we need to do something with that IList<WidgetTest> reference and be careful not to de-reference it.
public class Widget
{
public Widget()
{
_widgetTests = new List<WidgetTest>();
}
/// <summary>
/// This property is ignored by the NHibernate mappings.
/// </summary>
public WidgetTest WidgetTest { get; set; }
/// <summary>
/// For easier persistence with NHibernate, this property repackages the
/// WidgetTest property as a list containing a single item. If an
/// attempt is made to set this property to a list containing more than
/// one item, an exception will be thrown. But why bother? Just use the
/// WidgetTest property.
/// </summary>
private IList<WidgetTest> _widgetTests;
protected virtual IList<WidgetTest> WidgetTests
{
get
{
if (_widgetTests.Count == 0 && WidgetTest != null)
{
_widgetTests.Add(WidgetTest);
}
else if (_widgetTests.Count > 0 && WidgetTest == null)
{
_widgetTests.Clear();
}
else if (_widgetTests.Count > 0 && WidgetTest != _widgetTests[0])
{
_widgetTests.Clear();
_widgetTests.Add(WidgetTest);
}
return _widgetTests;
}
set
{
if (value != null && value.Count > 1)
{
throw new Exception("The WidgetTest collection may not contain more than one item.");
}
if (value != null && value.Count == 1)
{
WidgetTest = value[0];
}
else
{
WidgetTest = null;
}
//Store the reference
_widgetTests = value;
}
}
}
Mapping:
<class name="Widget" table="widgets">
...
<id name="Id" type="Guid" column="widgetId">
...
</id>
...
<bag name="WidgetTests" inverse="true" cascade="all-delete-orphan" access="property">
...
<key column="widgetId" />
<one-to-many class="WidgetTest" />
</bag>
</class>
Inspiration for the enhancement:
http://www.onkarjoshi.com/blog/188/hibernateexception-a-collection-with-cascade-all-delete-orphan-was-no-longer-referenced-by-the-owning-entity-instance/comment-page-1/