NHibernate
-
Does anyone have any strong opinions for or against NHibernate? I'm tempted to try it in my next project (having given Linq2Sql a try in the last), but if you guys say it sucks harder than Dyson, I won't bother.
-
Does anyone have any strong opinions for or against NHibernate? I'm tempted to try it in my next project (having given Linq2Sql a try in the last), but if you guys say it sucks harder than Dyson, I won't bother.
-
I hate that POS! Try it, but remember these words: Ultra Defensive Programming.
xacc.ide - now with IronScheme support
IronScheme - 1.0 alpha 1 out nowGot much better with 1.2, plus you now have stacks of tools for mapping, sp support etc. In the end, LINQ just makes it obsolete in my opinion. But don't be fooled either will give you automagic or event decent SQL output. In fact, for anything more complex it looks hideous. If you're in a rush or need to prototype, yeah sure I'd go with it and discard the whole thing once you get the model for the first iteration (you know, across layers). I guess LINQ would get you further in the long run. With all the caveats you shouldn't be (even if it is for that productivity sake) attempting to map tables to classes, or that ORM's such as NHibernate or LINQ are somehow a silver bullet, they are useful get up and running toys. For production or long-run work, it is far better to map out the model with XML properties for each field and deep within the database so all tiers or code-generation pieces can at least share a common metastore and be aware of its changes (testing, rules, loose coupling, docs, etc), rather than scattering it all over the place. But that depends on the type of apps and business domain you're in and whether you're building a one off or not.. ( from there you can satisfy the ORM tools too, but I think it is a wasteful exercise, evident if you look at all the "auto-magic build app straight from DB" marketing. It scks )
-
Got much better with 1.2, plus you now have stacks of tools for mapping, sp support etc. In the end, LINQ just makes it obsolete in my opinion. But don't be fooled either will give you automagic or event decent SQL output. In fact, for anything more complex it looks hideous. If you're in a rush or need to prototype, yeah sure I'd go with it and discard the whole thing once you get the model for the first iteration (you know, across layers). I guess LINQ would get you further in the long run. With all the caveats you shouldn't be (even if it is for that productivity sake) attempting to map tables to classes, or that ORM's such as NHibernate or LINQ are somehow a silver bullet, they are useful get up and running toys. For production or long-run work, it is far better to map out the model with XML properties for each field and deep within the database so all tiers or code-generation pieces can at least share a common metastore and be aware of its changes (testing, rules, loose coupling, docs, etc), rather than scattering it all over the place. But that depends on the type of apps and business domain you're in and whether you're building a one off or not.. ( from there you can satisfy the ORM tools too, but I think it is a wasteful exercise, evident if you look at all the "auto-magic build app straight from DB" marketing. It scks )
+ an ORM has a personality of Hugh Grant, you know, 0-dimensional actor.
-
Does anyone have any strong opinions for or against NHibernate? I'm tempted to try it in my next project (having given Linq2Sql a try in the last), but if you guys say it sucks harder than Dyson, I won't bother.
I looked into it briefly a while ago. It ended when i realized that, i'm using a relational database because i want to query relational data. If i just wanted to load and store object graphs, i'd make up a format and write my own serialization routines. Or heck, use XML. That, and the whole thing just stunk of metadata duplication. If i wanted to write an XML schema for my database, i'd either write code to do so automatically during initialization, thereby ensuring it was always up-to-date... or again, i'd just store the whole damn mess in XML and use XSD. I know there are people around who really dig ORM in general and NHibernate in particular, and i do hope they reply and give you the counter-argument. But, yeah... as much as i hate SQL, i hate clunky abstractions even more. IMHO, that's the one worthwhile feature of LinqToSql - when you write a query, it looks like a query. It doesn't look like a string or a black box or a horrendously long chain of method calls.
But who is the king of all of these folks?
-
Does anyone have any strong opinions for or against NHibernate? I'm tempted to try it in my next project (having given Linq2Sql a try in the last), but if you guys say it sucks harder than Dyson, I won't bother.
there is a war going on between database programming world and object oriented programming world . The problem is the object relational mismatch .I don't think LINQ solves the problem ,the unification promotes is far from the solution . I advise you to try out NHibernate . there are many recourses on the subject by the side of Object oriented programming approaching Relational db Patterns of Enterprise application architecture http://www.martinfowler.com/eaaCatalog/[^] and data access patterns http://helloworld.siteburg.com/content/databases/db2/0131401572_toc.html[^] i can think right now .
f(yf) = yf
-
Does anyone have any strong opinions for or against NHibernate? I'm tempted to try it in my next project (having given Linq2Sql a try in the last), but if you guys say it sucks harder than Dyson, I won't bother.
I've been using NHibernate for the last year or so and I've found it to be a mssive productivity enhancer. Although I'd advise that you also look at Castle ActiveRecord which is an easy to use attribute based wrapper that sits on top of NHibernate so that you do not have to manage lots of XML files all the time. Hibernate and ORM has become very commonplace in the Java world and have a proven track record of producing maintainable and safer code faster. It seems to be a lot less popular on .NET for some reason. Whitch I'd guess would be from the VB developer hatred of OO programming (and really any sort of change whatsoever) that seems to carry over to C# to a certain extent.
-
I've been using NHibernate for the last year or so and I've found it to be a mssive productivity enhancer. Although I'd advise that you also look at Castle ActiveRecord which is an easy to use attribute based wrapper that sits on top of NHibernate so that you do not have to manage lots of XML files all the time. Hibernate and ORM has become very commonplace in the Java world and have a proven track record of producing maintainable and safer code faster. It seems to be a lot less popular on .NET for some reason. Whitch I'd guess would be from the VB developer hatred of OO programming (and really any sort of change whatsoever) that seems to carry over to C# to a certain extent.
I am not an NHibernate user but the little bit I have had contact with I have not liked. I prefer letting the database do the stuff the database does well and letting the Web code get stuff via ODBC and Stored Procs. I am happy to admit that this is because I am used to doing things this way and, because it works and is secure, I have no reason to do things any other way. I don't know enough about NHibernate to understand how it interacts with the database, so I don't feel comfortable with trusting it.