GoDSatana,
Thanks for the suggestions. As you noted, having all those methods
would certainly add additional convenience to the Repository. But
there are a few reasons that the current iteration is designed the way
it is. In the previous version, 0.8.1 and before, the repository was
actually bigger with more methods such as Save and Update. In 0.9,
the more NHibernate centric methods, such as the two noted along with
Evict, were all moved to NHibernateRepository because they added
complexity to knowing what to use when and built the NHibernate
"signature" directly into the application. (Thanks for this
suggestion Kyle!) For example, Save and Update are NHibernate's way
of facilitating the persistence of domain objects with assigned IDs.
The more generic SaveOrUpdate really just says, "give me anything and
I'll make sure it gets persisted without you worrying about the
details." The Repository should be dead simple to use and understand
while covering the 80% of basic needs that it intends to provide.
But, with that said, there are times when the more NHibernate specific
methods are needed, such as the more explicit Save and Update
methods. But these should be the exception rather than the norm
(since assigned IDs are in cahoots with the dark forces in the world),
and are, consequently, available in the NHibernateRepository object.
But note that even the interface for this object doesn't require a
dependency on the NHibernate assembly. As you noted, we'd have to add
this reference to SharpArch.Core and, consequently, to
OurProject.Core. This is exactly what I'm trying to avoid. Yes,
we're all obviously using NHibernate if you're using S#arp
Architecture, but it doesn't mean that we should add direct references
to NHibernate from our domain layer. I've seen in past experiences
that this quickly leads to data concerns bleeding into the domain
layer which quickly leads to cats sleeping with dogs and general mass
hysteria.
I'd recommend that if you'd like to introduce more sophisticated
querying, you do one of two things; either simply extend the base
repository object and add your custom methods on a class by class
basis, such as is done within the tutorial in the documentation, or
add a new interface to YourProject.Core/DataInterfaces which
represents IYourIdealRepository.cs and which implements
INHibernateRepository. You can then provide all of the NHibernate
functionality you'd like and even add a reference to NHibernate to
your core layer to support ICriterion queries. This isn't something I
would recommend, but may be suitable in some situations; again, I
wouldn't do this without considering it very carefully for some time.
The other option, as Kyle noted, is to wait for version 3 which will
have the obligatory bloat which any framework degenerates to. ;)
Billy
On Nov 18, 6:29 am, "Kyle Baley" <
k...@baley.org> wrote:
> All the more reason to keep the base repository clean and adhering to DDD.
>