Separated Interface in practice

[stefan.moser]

Hi All,

I'm having a problem implementing the Separated Interface pattern from
Martin Fowler's book Patterns of Enterprise Application Architecture.
I'm using C# in Visual Studio 2005.

The problem I'm trying to solve is one of validation. Let's say I'm
building a book store application and I have a Genre object in my
Domain Model. When I'm adding a new genre, I want to validate the new
object to make sure that a genre with the same name does not already
exist. Naturally, I make a call to the Data Mapper asking for all
genre objects with the given name and see if any are returned.

This is where I encounter my problem. All of the layers in my
application are in their own assemblies (projects). The Data Mapper
already relies on the Domain Model because those are the objects that
it takes as parameters and returns from its methods. Therefore, I
cannot add a reference from the Domain Model to Data Mapper because it
would create a circular reference.

In the Data Mapper chapter of Patterns of Enterprise Application
Architecture, Fowler says the following:

"On occasion you may need the domain objects to invoke find methods on
the Data Mapper. However, I've found that with a good Lazy Load (200)
you can completely avoid this. For simpler applications, though, may
not be worth trying to manage everything with associations and Lazy
Load (200). Still, you don't want to add a dependency from your domain
objects to your Data Mapper.

You can solve this dilemma by using Separated Interface (476). Put any
find methods needed by the domain code into an interface class that you
can place in the domain package."

I understand that Fowler's first suggestion is to use a good Lazy Load,
but it is not a scalable solution to load every genre object just to
see if one exists with a given property.

So I then moved on to try and implement it using the Separated
Interface pattern. I created a data access interface my Domain Model
that my Data Mapper implements, just like Fowler suggests. The problem
is that I can't create an instance of my Data Mapper class (declared as
the Domain Model's data access interface.) I tried putting a factory
class in a separate project, but again ran in to the same problem
because that package would have to reference the Domain Model (because
the return types from the interface methods are domain objects) and
would also have to reference the Data Mapper (to create an instance of
the class.) Again, I've created a circular dependency.

I am sure that I'm not the first person to encounter this problem, any
help would be greatly appreciated!

Thanks,
Matt

 

[Guest]

Hi Stefan,

I had the same problem a while ago, and I solved it using the
AppDomain.CreateInstanceFromAndUnWrap mathod to instantiate an object from an
assembly without needing a reference to that assembly.

I don't have an example to show it (it was at my previous employer), but it
was not too difficult.

Hope this helps,

Joris

 

[Nick Malik [Microsoft]]

First off, the best place to post problems like this is on comp.object where
Martin actually hangs out.

Second, when you interpreted the following statement incorrectly:

You can solve this dilemma by using Separated Interface (476). Put any
find methods needed by the domain code into an interface class that you
can place in the domain package."

The problem
is that I can't create an instance of my Data Mapper class (declared as
the Domain Model's data access interface.)

You have bound the data mapper to the other interfaces in the domain model.
That was not the intent. The intent was to create an independent interface,
and place it in the domain package, where both the data mapper and the
domain model can see it during compile and reference, but where other
object, needing to create a data mapper, are not making a reference to the
domain model objects.

If this doesn't make sense, repost your question to comp.object to get a
better answer. The 'big brains' in OO design and patterns hang out there.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--