Question

I’m currently in the design phase of multiple rather complex systems which share common functionality (e.g. both have customer-relationship management (CRM) and sales functionality). Therefore I’m trying to extract the common part of the domain and reuse it in both applications.

Let’s say I have application A and application B, both using CRM functionality. For the most part, the CRM functionality is the same, but both applications like to augment some things related to CRM.

I’d like to create a library implementing a basic version of the CRM system, e.g. a customer is abstracted to

interface ICustomer {
  string CustomerNumber {get;set;}
}

and the base library has a basic implementation of ICustomer

class Customer: ICustomer

Application A can now augment this:

interface IACustomer : ICustomer {
    bool ReceivesNewsletter {get;set;}
}

class ACustomer : Customer, IACustomer {
   ...
}

Likewise, B has its own variation:

interface IBCustomer : ICustomer {
    string NickName {get;set;}
}

class BCustomer : Customer, IBCustomer {
    ....
}

For the purpose of abstraction, I never instantiate concrete types in the base library but use a factory or a DI container, e.g.:

interface ICrmFactory {
    ICustomer CreateCustomer();
}

A and B implement the factory accordingly such that ACustomers or BCustomers are created respectively.

Here’s a UML diagram of what I mean (application B is not shown):

For persistence I use NHibernate. Both A and B provide their own mapping (mapping-by-code) to include the extra properties. In addition, A defines IACustomer to be the proxy type of ACustomer and B defines IBCustomer to be the proxy type of BCustomer.

I can now use NHibernate to work with the entities in A and B, e.g. in A

session.QueryOver<ACustomer>()
    .Where(c=>c.ReceivesNewsletter)
    .List()

Now let’s say I want to do something with customers in the base library (for example in some kind of service object). I’ve just prototyped a very simple version and so far this seems to work fine:

session.QueryOver<ICustomer>()
   .Where(c => c.CustomerNumber == "1234ABC")
   .List()

That is, I can use the base class of the proxy type of a specific entity in QueryOver, and NHibernate creates the correct query, e.g. in A:

SELECT
    this_.Id as Id0_0_,
    this_.CustomerNumber as Customer2_0_0_,
    this_.ReceivesNewsletter as Receives3_0_0_ 
FROM
    ACustomer this_ 
WHERE
    this_.CustomerNumber = @p0;
@p0 = '1234ABC' [Type: String (4000)] 

My question

Will those queries always work as expected? Can I always safely use a base type of the proxy interface in my queries in the base library? Will NHibernate always find the “correct” entity type and table to retrieve? Or will there be situations where this affects query efficiency adversely b/c NHibernate needs to do guess work? Any other pitfalls I should be aware of in this scenario?

I could not find information about this in the documentation. This approach would allow me to neatly move common parts of some domains to their own base libraries, but I want to make sure it works.

Answer 1

I do not see a problem with this scenario.
Especially since there is only a single implementation to ICustomer in every application.

Even if you would have had more than one implementation for every application, you could experience some problems with loading by id (session.Load(42), because there can be more than one customer with that id,depending on your mapping). but queries to recieve lists of customers would still have worked.

When I looked into issues similar to yours with NHibernate in the past I read this article – its talks about a derived base class and not an interface,but it’s the same idea: http://codebetter.com/jameskovacs/2011/02/16/getload-polymorphism-in-nhibernate-3/

NHibernate does no guess work – upon initialization it builds a store of all of the mappings it has for any given type,when you write a query for any kind of type it will find the correct types it has mapped that inherit from it and query accordingly.