As a newbie to nHibernate, I am finding the creation of sessions to be a tad confusing.
Why doesn't nHibernate ship with something like what (i believe) Unit Of Work does?
or is there something built and UofW is more of an addon/preference? (context: ASP.NET MVC web application with SQL server).
Note: I am new to nHibernate, and spoiled with how MS does things. I would love it if things that are generally required to be shipped with the product download etc.
The session is kind of unit of work and also an identity map. You can create your own unit of work abstraction over it. Different applications need different kinds of unit of works and different programmers like different implementations too.
You won't need more than 50 lines of code to create your own unit of work implementation to abstract session and transaction management.
In case you haven't found it yet... there is a Unit of Work component for web applications that is part of the NHibernate Contrib project, called NHibernate Burrow. It is reasonably flexible and supports short (session-per-request) and long (sessions spanning more than one request) conversations.
I have used Burrow with ASP.NET MVC in the past and it works fine, though I haven't tried the long conversation in MVC. In it's current state, in order to use it, you will need to update the library references and compile the Burrow project. It's a little extra work but it's worth it.
I agree with Paco, although in a web application this can be a little more work.
I think the real issue is that most of us want to isolate our upstream code from a direct dependency on NHibernate and therefore we don't want to work directly against the session.
Once you wrap you head around NHibernate this abstraction becomes pretty simple but but it's a little harder to get your head around this abstraction at the same time you are trying to learn about NHibernate for the first time.
Related
I used NetTiers in a number of projects a job or two back. I found it extremely useful for generating back-end interfaces in ASP.NET webforms. The business and data layers were also pretty sweet. I typically use NHibernate, but I think it may be overkill on these particular projects in terms of the time it will take to get running.
Since then, I've been working on projects where practically everything is end-user facing. However, I've recently gotten a side project that will have a lot of back-end administrative stuff and was wondering if NetTiers is still as well-maintained and clean as it was a couple of years back. It doesn't appear to be, but I don't know if that means that it has actually been abandoned or if it has merely been moved elsewhere. Or is there another product (preferably a set of CodeSmith templates) that might work better for me? All I really need is a clean ActiveRecord model that can hit a SQL database on the backend and generate simple user interfaces for CRUD screens for most of my model objects. I need something that will do deep-loading of object graphs kind of like NetTiers will do as well.
Any suggestions?
I'm currently supporting a large NetTiers application and my experience has generally been one of frustration. I inherited the project and took over maintenance of the templates, fixing a number of bugs in the templates and applying some post-generation scripts to the generated files. IMHO the generated code is overly verbose, suffers from massive duplication, and would benefit from more use of generics. The templates I'm working with didn't dispose of resources correctly (the newer template versions may be better). At one point I considered upgrading to a newer version but the size of the exercise put me off. Useful documentation is difficult to find and getting answers to NetTiers questions is not straight forward. The overall impression I have is one of gradual decline.
If you're just after a simple .Net stack for generating a UI from a SQL database I suggest you take a look at ASP.NET MVC3 with MvcScaffolding and Entity Framework. Add AutoMapper and Munq for DI.
We have been using NetTiers for several years now. I think it tend to look overwhelming for first time users, in terms of quantity of stuff generated, and there are a couple of limitations around the DeepLoad functionallity and circularities. I too have the feeling that there have not been many updates lately, but in the overall I've had a great experience using Nettiers with codesmith, and from all the ones I've tried, it's clearly our favorite, with huge productivity gains. We use views, custom sp's, the indexes, etc.
In a comment to another reply: We've tried Automapper, and moved away from it due to the fact that it fails silently when the object's structures change. And moved away from Entity Framework because we don't like hand-coding our DALs. :)
I stumbled across Castle Active Record a few weeks ago and thought that it looked like an interesting solution to the laborious CRUD tasks associated with data driven applications. It seems pretty mature now and am considering using it for the data layer of an application I am developing, but I was wondering:
How well it scales? (i.e. does the extra layer over NHibernate scale well)
What are its biggest limitations that will cause frustration once you are too far into development to change direction easily?
Is using straight NHibernate without the Active Record layer a better long term option?
Personally, I think that Active Record pattern itself and the Castle's baby definitely have some advantages, like:
simplified configuration
the AR pattern - 'entity is independent'. Sometimes it just it's the project more that anything else.
you can start developing and using AR really quickly in your project. Just define proper mappings, add some config and you can already do some basic stuff with entities. That part seems faster than pure nh for me.
SessionScope + TransactionScope classes that are in AR are there for you already. This is something you will have to write yourself for nh if you have to e.g. support transaction inheritance.
all Castle projects just works beautiful together. AR + Facilities + Windsor = very powerful stack.
there's new version of AR (finally!) that works on top of NH 3.0.
But there are also some disadvantages:
the myth of overhead. I feel it's not something I can define, but it's just that feeling that all this session management, wrappers etc. just have to cost something. But I think in reality it's quite elusive.
if you need to do something custom you just HAVE to touch nhibernate guts. It seems to be pretty complicated with AR.
no 2nd cache support
AR mappings are not POCOs. Might be an issue when serializing through WCF or just sending between different layers. It's not the case with NH.
AR is just not the best way to force OO approach for repositories/dao classes. But that's nothing new because it's pure consequence of AR pattern - your object knows how to save or delete himself. But it's becoming a pain when your project grows a little bigger.
So in the end, it's a great framework to use with simple or medium complex projects. It's good for asp.net/winforms, doesn't matter. With pure NH, you will definitely have to code much more to make similiar application. But if you'll do it, you will be much happier. Because you'll be able to control everything.
As always, it's all up to your preference or project. For small, quick projects - AR is the way, for medium - I would say NH is THE way!
p.s.
oh, by the way, AR makes exactly the same queries, so it's like using nh to talk to db. NH scales and so does castle. Just avoid 'n+1' problem and think about laziness and you should be good;P
p.s.
listen to Mauricio Scheffer, he really knows what he' writing about.
What is NHibernate Interceptor, and what purpose does it serve in an application?
Also, in this article, I learned that using NHibernate makes a desktop application slower at startup, so to avoid this, I need to save the configuration in a file, and later load it from the saved file. How can I do that? I didn't find any examples in that tutorial.
An interceptor allows you to execute additional functionality when an entity is retrieved / deleted / updated / inserted in the DB ...
Interceptors article
Hibernate doc
other useful info
About making your app slower:
I'd suggest that you only have a look at optimizing start-up time, when it really becomes a problem.
When you build a session-factory, NHibernate will parse all the mappings, and that is an operation that is a bit expensive. But, as long as you have a limited number of entities, the performance hit isn't that big.
I have never ever had to optimize the initialization of NHibernate, because of slow startup times.
I'd suggest that you first concentrate on the core of your application -the problem you're trying to solve- and afterwards have a look on how you could improve startup performance.
(If you'll ever have to do it).
Interceptors, like the name itself says, allows you to intercept NHibernate operations (save/update/delete/load/flush/etc).
A newer, more flexible API to achieve this is the event system.
About serializing the configuration, the code is there, it's the class Effectus.Infrastructure.BootStrapper which is called at application startup.
An interceptor's dissection series written by me can be found in here
http://blog.scooletz.com/2011/02/03/nhibernate-interceptor-magic-tricks-pt-1/
hope it helps
While this is a subjective question, as a new NHibernate user, I'm curious as to why one would choose Fluent vs traditional XML mapping.
From my standpoint, when I first worked with NHibernate, I used the Fluent interface, but ran into some roadblocks and had a hard time finding adequate documentation for the Fluent interface for anything beyond a 'toy app', so I learned to handle these via XML.
Over time, I realized I did most of my work on the XML side, and realized it was not as horrific as I thought it would be. So for me personally, it was a case of poor documentation and not seeing a significant savings in coding time.
That being said, there may be some huge advantage/disadvantage that I'm missing, and I'd really like to hear some opinions from folks who have more experience in working with these tools.
Compile-time safety and refactoring (renaming classes, properties) are one of the benefits you get from fluent mappings. Using one language (C# or VB.NET) to write mappings, program code and data access is another benefit.
Compile-time name- and type-safety
IntelliSense to show you which fluent methods are available at any point
Customizable defaults
Automapper
For me, the big feature in Fluent is the Automapper.
I can define my domain model using POCO classes, (mostly) without worrying about the nasty details of how they will be mapped to tables in a relational database.
As a long time OO developer, and occasional DB developer, I'm much more comfortable designing in an OO fashion. I also believe that this allows me to work at a higher, more powerful level of abstraction.
Automapping also makes ongoing changes to the domain model much less daunting.
Your customers have just told you at the last minute they want to add four new columns to the database?
No problem - add four new properties to the associated POCO (4 lines of code), and remap.
Takes a lot of the pain out of the constantly changing requirements that are a fact of life on many projects.
I'll add a reason that is very important for making custom functionality based on a common code base:
With fluent you can override mappings to add a new field. Changes to the existing (superclass) mappings are automatically incorporated into the customization/branch. I was forced to use Fluent to avoid maintaining a seperate .hbm/xml file for each customer. Glad I did :)
Like a lot of open source software, this library was available to the public before a lot of the features were production ready. Depending on what version of FluentNhib you were working with, some features may not have been implemented at all. For example, when I first started working with it, composite keys had not been implemented yet and I found stumbling block after stumbling block.
But the product has evolved into quite a great tool. It's pretty feature complete compared to xml and provides all the benefits others have outlined already.
What are the opinions of the software developers who have used Spring.NET and NHibernate in their projects? In couple of our projects in the company where I work, we have used these third party tools very extensively and we have gained tremendous productivity. A little caveat is that it is a little challenging for junior .Net Developer to grasp the concept.
Imo, Spring.Net and NHibernate go hand in hand: If you master the learning curve you will be very pleased when Spring is used for (almost transparent) transaction handling for NHibernate, Dependency Injection as well as Db:Provider handling.
NHibernate (or similar ORM's) can be extremely helpful with "greenfield" development, where the domain object model can be designed properly, and then the database schema and NHibernate mappings can be code-generated to match the model. On the other hand, NHibernate can be very tough to apply to a legacy or poorly normalized database. Although it has support for handling some unusual data structures, the learning curve is much higher for those techniques.
I can't say much about Spring.Net except that in 2007, our team tried to implement it into an existing, complex solution to handle DB transactions and entity validation, but we scrapped the idea after a week of work. Our resident Spring/Java expert concluded that Spring.Net was a couple versions behind Spring and wasn't mature enough to handle the use cases in our project. Disclaimer: not sure what version of Spring.Net that was, so things may have improved recently.
There has lot of benefits using spring.net/nHibernate.
For data access you are able to take full advantage of nHibernate ORM with lazy loading, database independent programming, easy save load update delete your entities. No need to write any query to do that. That is why after designing a database and after development if any change is required at any state of development it is very much easy to change.
Dependency Injection(DI) helps to separate the UI and business logic. That is why any time you are able to change your graphical user interface without breaking any business logic. Same way if you need any change at business logic then need only build business layer. And it is also configurable.
Aspect Oriented Programming (AOP) is another feature of Spring.Net. It helps logging application, dynamic method interception allow more control over method call. It makes easy to authorize application. Declarative transaction management is a nice feature to manage transactions. You do not need to write code for start stop database connection. Just write at configuration file at which method you want to maintain transaction. So at large scale project it will save lot of time and will give you more flexibility over transaction management.
Spring webservice is very easy to write and consume from a client. Not need to add any custom attribute, no WSDL. You can intercept every method call, you are able to add advice like logging advice, authentication/authorization advice.
Overall it save approximately 33% of development time, make application more maintainable, highly configurable.