Manning is running a special on "NHibernate in Action" for $10. NHibernate In Action was released in February 2009 for V1.2 of NHibernate. Currently, NHibernate is up to V2.1. Will the book about V1.2 be relevant enough to apply towards the current release of NHibernate. I don't want to waste my time and money on a book about deprecated or irrelevant features.
I'm a complete NHibernate noob, but I'm not a stranger to the general concept of ORM's.
Update:
I did buy the book, and from the small amount that I've read the V2.x series was in beta when the book was released. The book's authors do point out some of the differences in configuration between 1.x and 2.x. From what I've read so far, I recommend this book to anyone wanting a book about NHibernate.
Yes, it will still be relevant. You can find core definitions about ORM systems in it.
Also there are a lot of examples about mapping and solving common problems like inheritance mapping, collections mapping, caching, etc.
After some digging I found this post, which linked to this blog, which actually gave a few bits of detail on NH2.1 but no sales pitch. This is the main problem NHibernate has in my view - they don't go for selling themselves in a big way but like to "keep it in the family", you have to dig through developer's blogs.
Anyway the release notes is where you're told to look. releasenotes.txt contains the entire history and here's some pickings from 2.0 and 2.1:
.NET 1.1 is no longer supported
Nullables.NHibernate is no longer supported (use nullable types of .NET 2.0)
NHibernate.Expression namespace was renamed to NHibernate.Criterion
<nhibernate> section, in App.config, is no longer supported and will be ignored. Configuration schema for configuration file and App.config is now identical, and the App.config section name is:
<hibernate-configuration> have a different schema and all properties names are cheked
configuration properties are no longer prefixed by "hibernate.", if before you would specify "hibernate.dialect", now you specify just "dialect"
NHibernate will return long for count(*) queries on SQL Server
Various classes were moved between namespaces
Various classes have been renamed (to match Hibernate 3.2 names)
AutoFlush will not occur outside a transaction - Database transactions are never optional all communication with the database must occur inside a transaction, whatever you read or write data. (This one may affect what you read in the book, see this question)
case when...then...else...end in select clause
There are around a hundred others but nothing that will affect you if you're not trying to upgrade from 1.2 to 2.1.
I've just bought the book, and am finding it very useful and relevant. Much of the important stuff is conceptual anyway. My bigger gripe is the fact that I'm using fluent nhibernate, so lots of the xml and attribute mapping and config stuff in the book is not so relevant to me.
Related
I recently posted a question regarding NHibernate. This lead me to check Codesmith's framework PLINQO for NHibernate.
At the same time, i was reading a tutorial on nhibernate at their official site (as i was looking at the generated project by PLINQO).
I am not an expert on NHibernate but what i am looking at right now (PLINQO Generated NHibernate project) looks to me very sloppy, pretty much a recipe for disaster. It creates a set of "Entities" that i am guessing is the business object? A big mess to my eyes.
Does anyone has experience with Codesmith's NHibernate?
Can anyone point me to a mc daddy of NHibernate. I have found so many variants so far that i am already overwhelmed with all this.
Thanks you.
I work for CodeSmith Tools. How do you feel the generated project looks sloppy? How would you improve it? We try to separate out the entities (POCOs) / hbm's for consistency and easy of use (as Randy detailed above). The Entities are generated directly from what is defined in the hbm file, which can be customized without losing your changes.
The generated project follows the architecture of Linq-to-SQL and Entity Framework. We feel this allows developers on the Microsoft Stack to switch between backends quickly (NHibernate to EF or EF to NHibernatE) while minimizing the amount of code changes.
The generated datacontext manages the NHibernate sessions for you while giving you access to query extensions, caching and much more. Also, you don't lose any core NHibernate features as we just extend the core libraries. All of the core features are available on the DataContext under an advanced property.
P.S., The best place to post questions and get a timely response is via our forums.
Question says it all. Working with an old codebase that is using NHibernate 1.2. What do I stand to gain, and what will I lose, or experience in pain, as part of this upgrade? Is the total effort worth the benefit, and if so, what are those benefits? And while I'm at it, would it make sense to just move to Fluent NHibernate?
This really depends on what nhibernate functions you are using. Take the release nodes and see if anything is in there you are using. Most functions are still working the same in 3.2. You have to do some upgrades in your mapping files.
I would do one change at the time. So get it working without Fluent, and decide if it is worth doing going to fluent. You should also have a look a QueryOver and the usage of linq.
One of the most interesting new features in NH 3.2 is that you can now map with code, instead of with HBL files. This is the same feature that FNH has had for years, but integrated into the main NH project.
I have not used this myself in NH (I'm a big fan of FNH Automapping), but my reading indicates that many FNH users consider this much less mature than the FNH equivalent.
One area where FNH is still miles ahead of NH is the aforementioned Automapping. NH just does not do that yet (though there are some misleading blog posts which imply that it does).
Probably not of much value for your current project (you've already gone through the pain of setting up your HBL files), but could be very valuable for new projects. We use it in our project, and it allows us to almost change our object model at will, and let Automapping rebuild the database for us.
Lastly, as I write this there is no official release for FNH with NH 3.2. I've been experimenting with the latest FNH builds (1.3), and it's "not quite there yet". But it probably will be soon.
Nhibernate 3.2 has a mostly functional Linq provider, which is nice if you like Linq.
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.
Can anyone throw some light on tools that can be used with NHibernate and which perform the below mentioned tasks:
Generates the Mapping File
Generates the Entity Class
Generates the Configuration file
And also provide information whether these tools are open source or licensed.
Thanks
One tool I've used that did a decent job was CodeSmith. It looked at the existing database and created the entities, mappings and configuration file. However, this is only to be used as a starting point as there are many tweaks you'll likely want to do to make it more usable and better performing. Things such as when to lazy load vs. eager load, creating subclasses or components. This tool really just mimics the database structure in your entities which is not always the best way to represent in code.
This is a licensed solution but it includes a fully functional demo you can use to gen your files initially. After that, you'll most likely just enhance just as you would your database.
Another is MyGeneration. Same thing, it'll get you 75% of the way there in most cases.
Just be cautious as to which version of NHibernate these tools are producing. They may be using an older version which may have some obsolete code.
I really like Visual NHibernate (http://www.slyce.com/VisualNHibernate/).
Not free, but has a nice set of features, including the definition of templates for the entities, and generating both HBM.XML as well as Fluent NHibernate mappings.
A similar question with some answers you might find useful is already on SO.
NHibernate Generators
As mentioned in that question's answers, fluent NHibernate is a good option. It just went RTM. You can find more info at http://fluentnhibernate.org/
Check out LLBLGen Pro. It's got a competing ORM but can also act as a code generator for nhibernate. Very good for DB first work.
I need to collect some information about existing ORM solutions.
Please feel free to write about any programming language.
Can you tell about the best ORM framework you ever use and why is it better then others?
I used NHibernate and Entity Framework.
Current stable version of entity framework is very immature. It is too difficult, or impossible to perform common tasks. Testing your code is also difficult since you cannot really separate your entities from your data access classes. But it perfectly integrates with visual studio ide. Setting up is easy and updating all the models from database takes just a few seconds. Upcoming version of EF (4.0) will solve some of this problems.
NHibernate is quite powerful. It supports plain old clr objects, so you can work with simple entities. Configurations provide great control in great detail. Framework capabilities are satisfying and it has a large and active community and good documentation. Setting up and updating entities is a little difficult since you must use generators that looks up your database and generates entities and xml files. It may be tricky to find a generator or a template that exactly fits your needs. But once you set all things up, you will love it.
I found LINQ to SQL to be a pretty straight forward solution. The first time I used it, I'd say I had a basic ORM working within a few hours, and was creating LINQ queries with it.
Microsoft has an additional ORM (Entity Framework), which I've heard is more complex but may be useful for highly complex distributed applications with multiple data sources etc.
Overall I found LINQ to be an easy and fast to use ORM.
I have been looking at Telerik Open Access for last few months, in genernal this ORM has been a pain to work with, it was advertised as having extensive linq support but in reality many of the linq features you would normally expect dont work server side and are performed on the client. I also had problems using multiple conditions in a where clause, see my last question. Here are a few things that i found
No support for views
Unable to map more than one entity to the same table
Inheritance and Interface support requires you to make changes to you database schema
No visual designer like LINQ to SQL and Entity Framework
If you want to perform an insert any related entities must be fetched first
Rohan
LINQ2SQL was nice, EF makes sense, but is very complex and SQL Server oriented. NHibernate is special and Telerik OpenAccess (fully .NET / Visual Studio) got a broad set of functionality and professional support.
Since I know the product I can comment on Rohan's concerns:
Existing Views can be used and full Views support is coming up
Mapping more than one entity to the same table "works" for class hierarchies, limitation with reverse mapping exists
Inheritance and Interfacer support "do not require" changes to the the database schema, again limitation with reverse mapping exists though
Visual Designer will come, Forward and Reverse Mapping Wizards allow you already to do anything in an easy way
There is a workaround for the insert issue mentioned and it will be fixed generally
Check out the Telerik site to find happy customers and feel free to use the telerik forums and support resources for any question.
-Peter
Im new to OpenAccess ORM and we are using two products. Reporting and OpenAccess.
I think there are some features that people missed.
OpenAccess uses graphical designers while nHibernate still uses handwritten xml files
OpenAccess is not limited to SQl Server as EF4 and similiar frameworks
using it is easier and the forums are pretty helpful.
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster