I'm looking for more information on the extension points within NHibernate.
For instance I know about IUserType and ICacheProvider. However I can't seem to find a good reference of all the different extension points that NHibernate provides?
Is anyone's Google-fu stronger than mine :)
There are no complete references on that... but it's not hard to look at the assembly and find the interfaces and base classes:
IInterceptor
IBatcherFactory
ICollectionTypeFactory
IProxyFactoryFactory
ICacheProvider
IConnectionProvider
ICurrentSessionContext
Dialect
IDriver
IIdentifierGenerator
ITuplizer
And many more...
Take a look at *EventListener (newer mechanism) and IInterceptor (older mechanism, but useful in certain scenarios that EventListeners don't cover). They will get you a long way WRT extending/integrating with NHibernate.
http://www.nhforge.org/doc/nh/en/index.html#events
Related
I'm currently trying out a few different ways of implementing repositories in the project I'm working on, and currently have a single repository with generic methods on it something like this:
public interface IRepository
{
T GetSingle<T>(IQueryBase<T> query) where T : BaseEntity;
IQueryable<T> GetList<T>(IQueryBase<T> query) where T : BaseEntity;
T Get<T>(int id) where T : BaseEntity;
int Save<T>(T entity) where T : BaseEntity;
void DeleteSingle<T>(IQueryBase<T> query) where T : BaseEntity;
void DeleteList<T>(IQueryBase<T> query) where T : BaseEntity;
}
That way I can just inject a single repository into a class and use it to get whatever I need.
(by the way, I'm using Fluent NHibernate as my ORM, with a session-per-web-request pattern, and injecting my repository using Structuremap)
This seems to work for me - the methods I've defined on this repository do everything I need. But in all my web searching, I haven't found other people using this approach, which makes me think I'm missing something ... Is this going to cause me problems as I grow my application?
I read a lot of people talking about having a repository per root entity - but if I identify root entities with some interface and restrict the generic methods to only allow classes implementing that interface, then aren't I achieving the same thing?
thanks in advance for any offerings.
I'm currently using a mix of both generic repositories (IRepository<T>) and custom (ICustomRepository). I do not expose IQueryable or IQueryOver from my repositories though.
Also I am only using my repositories as a query interface. I do all of my saving, updating, deleting through the Session (unit of work) object that I'm injecting into my repository. This allows me to do transactions across different repositories.
I've found that I definitely cannot do everything from a generic repository but they are definitely useful in a number of cases.
To answer your question though I do not think it's a bad idea to have a single generic repository if you can get by with it. In my implementation this would not work but if it works for you then that's great. I think it comes down to what works best for you. I don't think you will ever find a solution out there that works perfectly for your situation. I've found hybrid solutions work best for me.
I've done something similar in my projects. One drawback is that you'll have to be careful you don't create a select n+1 bug. I got around it by passing a separate list of properties to eagerly fetch.
The main argument you'll hear against wrapping your ORM like this is that it's a leaky abstraction. You'll still have to code around some the "gotchas" like select n+1 and you don't get to take full advantage of things like NH's caching support (at least not without extra code).
Here's a good thread on the pros and cons of this approach on Ayende's blog. He's more or less opposed to the pattern, but there are a few counter arguments too.
I've implemented such kind of repository for NHibernate. You can see example here.
In that implementation you are able to do eager loading and fetching. The pitfall is that with NH you will often need to be able to use QueryOver or Criteria API to access data (unfortunately LINQ provider is still far from being perfect). And with such an abstraction it could be a problem leading to leaky abstraction.
I have actually moved away from repository pattern and creating a unit of work interfaces - I find it limiting.
Unless you anticipate a change in the datastore i.e. going from DB to textfile or XML - which has never been the case for me, you are best off using ISession. You are trying to abstract your data access and this is exactly what NHibernate does. Using repository limits really cool features like Fetch(), FetchMany() futures etc. ISession is your unit of work.
Embrace NHibernate and use the ISession directly!
I've used this approach successfully on a few projects. It gets burdensome passing in many IRepository<T> to my Service layers for each BaseEntity, but it works. One thing I would change is put the where T : on the interface rather than the methods
public interface IRepository<T> where T : BaseEntity
I would like to implement IdbSet to provide my DbContext a custom implementation that will essentially serve to filter my data for the currently logged in user (I am working on a multi-tenant application). The general idea I am going with is very similar to this post: Can a DbContext enforce a filter policy?
However, it is not clear to me how to make DbContext "know" about how to use my own class that implements IDbSet. I am having a tough time finding documentation on this. Any pointers would be helpful!
TIA,
-jle
I'm almost sure that you cannot create your own implementation of IDbSet and pass it to entity framework. Such implementation will lose all stuff related to EF which is internally implemented in DbSet itself - by internally I really mean that there is no public API to replace it. IDbSet interface is provided not because it is supposed to create your own sets but because it allows mocking sets when unit testing application. The only way you can extend functionality is either:
Inheriting DbSet but I'm afraid that it will not help you as well because methods / properties will not be marked as virtual.
Creating custom IDbSet implementation which will wrap DbSet. This looks like the best chance but you can still find that DbContext doesn't like your new implementation. I gave this very quick try but I was not successful. My implementation worked for persisting but not for querying.
I have discovered the method T Generic() in the abstract class ToManyBase<T, TChild, TRelationshipAttributes> but I cannot find any documentation or examples of how this is used, or what it does. Can anyone enlighten me a bit?
Nothing of significance.
It's the equivalent of the NHibernate generic= attribute, which is simply away of explicitly specifying that a collection is a generic one. A holdover from NHibernate's pre-generic days.
Hey there, I've started to play around with Fluent NHibernate and now I want to could do something like IDbSet<T> like I could in EF Code First.. However I cant find any equivalent interface?
Thanks in adavance!
In NHibernate you operate with entities through the ISession interface (reference docs with example). You may wrap the session in a repository if you want (example: Sharp Architecture repository)
I have come across fluent API's while studying DSLs.
I have searched a lot on fluent API's...the basic conclusion which I could draw was that fluent a API uses method chaining in order to make the code fluent.
But I cannot understand - in object oriented languages we can always create an object and can call the methods related to it. Then how is a fluent API different? What other features does a fluent API add?
With a fluent interface you write methods that return the object that the method was invoked on (usually self or this) and handle traditional return values as a state change in that object. If you look at say some of the Javascript libraries that use a fluent interface it makes it far easier to deal with lists and nulls as they can be handled the same way you would a single object. The disadvantage of fluent interfaces is that they tend to create monolithic god objects that have a whole heap of responsibilities.
I wouldn't want them to be used everywhere (because of the god object problem) but they are nice from time to time.
Your question is answered in the originating Fluent Interface blog post by Martin Fowler. The point is that the fluency in fluent API comes from the domain of a domain specific language, not only method chaining.
Fluent API is an advanced way of specifying model configuration that covers everything that data annotations can do in addition to some more advanced configuration not possible with data annotations.
And Web API is a programming interface/application type that provides communication or interaction between software applications.