Repository and NHibernateRepository

[GoDSatana]

I have found some misconception in Repository and NHibernateRepository
1) Update and Save methods should go to the Repository
2) SaveOrUpdate method should go to the NHibernateRepository
Also i think that you can add some other methods into the
NHibernateRepository
1) void Refresh(T entity); refreshes an entity from the DB
2) void Attach(T entity); attaches an entity to a current session if
it is not there
Also it will be good to add methods like :
1) IList<T> GetAll(int pageNumber, int pageSize, params Order[]
orders);
2) IList<T> GetAll(int pageNumber, int pageSize);

3) IList<T> GetByCriterion(params ICriterion[] criteria);
4) IList<T> GetByCriterion(int pageNumber, int pageSize, params
ICriterion[] criteria);
5) IList<T> GetByCriterion(int pageNumber, int pageSize,
IEnumerable<ICriterion> orders, params ICriterion[] criteria);

6) IList<T> ExecuteSQLQuery(string queryString);
7) IList<T> ExecuteSQLQuery(string queryString, int pageNumber, int
pageSize);

10) IList<T> ExecuteHQLQuery(string queryString);
9) IList<T> ExecuteHQLQuery(string queryString, int pageNumber, int
pageSize);

11) IList<T> ExecuteQuery(IQuerable<T> querable);
12) IList<T> ExecuteQuery(IQuerable<T> querable, int pageNumber, int
pageSize);

These signatures are not final, they are just for an examples? that
should be discussed...
To add some of these methods we need to have a reference in the Core
project to the NHibernate.dll.
So may be we should move NHibernate classes from the Coreproject to
something like NHibernateCore?

[Kyle Baley]

That's a lot of methods. Seems to me it is starting the path down to bloatware, which shouldn't happen until at least version 3. I would consider each one carefully before adding it. I've used NHibernate only on a small handful of projects but in those cases, we didn't have a need for paging (at that level) or directl SQL/HQL access. As it is, I would avoid using the NHibernateRepository if I could. There is way too much infrastructure knowledge in there. Maybe someone with more experience would disagree. The criterion methods might be a good idea but my concern there is that now, the NHibernate API is leaking out to the caller.

 

My first impression (and I'm not wedded to it) would be to keep this lean and let the user extend it with the extra functionality you describe.

[GoDSatana]

Different users have their own likes and dislikes.
So one wants to write queries in plain SQL, the other wants to use
Criteria API, somebody wants to use LINQ queries...

On Nov 18, 1:31 pm, "Kyle Baley" <k...@baley.org> wrote:
> That's a lot of methods. Seems to me it is starting the path down to
> bloatware, which shouldn't happen until at least version 3. I would consider
> each one carefully before adding it. I've used NHibernate only on a small
> handful of projects but in those cases, we didn't have a need for paging (at
> that level) or directl SQL/HQL access. As it is, I would avoid using the
> NHibernateRepository if I could. There is way too much infrastructure
> knowledge in there. Maybe someone with more experience would disagree. The
> criterion methods might be a good idea but my concern there is that now, the
> NHibernate API is leaking out to the caller.
>
> My first impression (and I'm not wedded to it) would be to keep this lean
> and let the user extend it with the extra functionality you describe.
>

[Martin Hornagold]

Seems odd to put paging on the repository to me.
This is a view issue and should be handled by the controller.

[Kyle Baley]

All the more reason to keep the base repository clean and adhering to DDD.

[Billy]

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.
>