domain design with nhibernate

Question

In my domain I have something called Project which basically holds a lot of simple configuration propeties that describe what should happen when the project gets executed. When the Project gets executed it produces a huge amount of LogEntries. In my application I need to analyse these log entries for a given Project, so I need to be able to partially successively load a portion (time frame) of log entries from the database (Oracle). How would you model this relationship as DB tables and as objects?

I could have a Project table and ProjectLog table and have a foreign key to the primary key of Project and do the "same" thing at object level have class Project and a property

IEnumerable<LogEntry> LogEntries { get; }

and have NHibernate do all the mapping. But how would I design my ProjectRepository in this case? I could have a methods

void FillLog(Project projectToFill, DateTime start, DateTime end);

How can I tell NHibernate that it should not load the LogEntries until someone calls this method and how would I make NHibernate to load a specifc timeframe within that method?

I am pretty new to ORM, maybe that design is not optimal for NHibernate or in general? Maybe I shoul design it differently?

score 2 · Answer 1 · edited May 23 '17 at 12:04

2

Instead of having a Project entity as an aggregate root, why not move the reference around and let LogEntry have a Product property and also act as an aggregate root.

public class LogEntry
{
    public virtual Product Product { get; set; }
    // ...other properties
}

public class Product
{
    // remove the LogEntries property from Product
    // public virtual IList<LogEntry> LogEntries { get; set; }
}

Now, since both of those entities are aggregate roots, you would have two different repositories: ProductRepository and LogEntryRepository. LogEntryRepository could have a method GetByProductAndTime:

IEnumerable<LogEntry> GetByProductAndTime(Project project, DateTime start, DateTime end);

edited May 23 '17 at 12:04

Community

1
1

answered Jun 19 '12 at 16:06

Miroslav Popovic

12,100
2
35
47

It kind of feels strange to make a simple log entry and aggregate root or even an entity. It just has a few simple probperties like timestamp, message, logged value, projectID. It doesn't have any child entities. It feels more like a dumb value object. – bitbonk Jun 19 '12 at 19:51
1

Maybe, but it should be a good compromise, against fighting with NHibernate's default list behavior. I would love to hear few more opinions on this though. It's an interesting subject. – Miroslav Popovic Jun 19 '12 at 20:16

score 1 · Accepted Answer · answered Jun 20 '12 at 12:33

The 'correct' way of loading partial / filtered / criteria-based lists under NHibernate is to use queries. There is lazy="extra" but it doesn't do what you want.

As you've already noted, that breaks the DDD model of Root Aggregate -> Children. I struggled with just this problem for an absolute age, because first of all I hated having what amounted to persistence concerns polluting my domain model, and I could never get the API surface to look 'right'. Filter methods on the owning entity class work but are far from pretty.

In the end I settled for extending my entity base class (all my entities inherit from it, which I know is slightly unfashionable these days but it does at least let me do this sort of thing consistently) with a protected method called Query<T>() that takes a LINQ expression defining the relationship and, under the hood in the repository, calls LINQ-to-NH and returns an IQueryable<T> that you can then query into as you require. I can then facade that call beneath a regular property.

The base class does this:

protected virtual IQueryable<TCollection> Query<TCollection>(Expression<Func<TCollection, bool>> selector)
        where TCollection : class, IPersistent
    {
        return Repository.For<TCollection>().Where(selector);
    }

(I should note here that my Repository implementation implements IQueryable<T> directly and then delegates the work down to the NH Session.Query<T>())

And the facading works like this:

public virtual IQueryable<Form> Forms 
{ 
    get 
    { 
         return Query<Form>(x => x.Account == this); 
    } 
}

This defines the list relationship between Account and Form as the inverse of the actual mapped relationship (Form -> Account).

For 'infinite' collections - where there is a potentially unbounded number of objects in the set - this works OK, but it means you can't map the relationship directly in NHibernate and therefore can't use the property directly in NH queries, only indirectly.

What we really need is a replacement for NHibernate's generic bag, list and set implementations that knows how to use the LINQ provider to query into lists directly. One has been proposed as a patch (see https://nhibernate.jira.com/browse/NH-2319). As you can see the patch was not finished or accepted and from what I can see the proposer didn't re-package this as an extension - Diego Mijelshon is a user here on SO so perhaps he'll chime in... I have tested out his proposed code as a POC and it does work as advertised, but obviously it's not tested or guaranteed or necessarily complete, it might have side-effects, and without permission to use or publish it you couldn't use it anyway.

Until and unless the NH team get around to writing / accepting a patch that makes this happen, we'll have to keep resorting to workarounds. NH and DDD just have conflicting views of the world, here.

So your entities have a dependency on the repository (or multiple repositories for that matter)? Is that common in DDD? — bitbonk, Jun 20 '12 at 12:50
Probably not. I'd describe our approach as inspired by DDD but not slavishly following it. In our scenario there's no huge disavantage to this - if I were being 'pure' then I'd do it differently. But who has time for pure? :-) — Neil Hewitt, Jun 20 '12 at 12:53
Well I guess at least I should have my IRepository injected into my Entity (preferably ctor-injected). You do it with ambient context, which tend to be a bit problematic at times. What is the reason in your case for this decision? — bitbonk, Jun 20 '12 at 13:00
We used to use Unity for IoC and I found it problematic with NHibernate for a number of reasons. In the end we decided that we were happy with direct dependencies - we're happy to say we'll stick with NHibernate. The Repository.For static method is 'injecting' repository instances on-demand instead of at ctor-time; it used to resolve IRepository using Unity to allow for mocks etc. But it became too much of an overhead for a small project. — Neil Hewitt, Jun 20 '12 at 13:28
Actually, that doesn't really answer your question. I haven't found ambient context to be troublesome, and because NH requires all persistent types to have a parameterless constructor, ctor-injection is out unless you put in your own factory for NH - which opens up a whole other can of worms. So we just sidestepped that problem. — Neil Hewitt, Jun 20 '12 at 13:34

domain design with nhibernate

2 Answers2