Why nHibernate [modified]
-
I wonder if my hatred for nHibernate and alike are not too exaggerated. I avoid using them at all times and have always preferred writing my own persistence layers. I had some bad experiences with these kind of tools and hate to loose control of how things are done. I know this comes at the cost of overall productivity, but in the end I believe it saves me time when I don't need to create super duper workarounds because the framework does something I didn't tell it to do. Or worse, as has happened on a project I worked. The lead architect decided to use LINQtoSQL and the entities generated were complex rendering the system unusable for performance reasons. Despite all tuning efforts, it was not enough and if it wasn't for the ORM, tuning the data layer would be much easier and feasible and we wouldn't need to rewrite the whole data layer using classic ADO.NET implementation. And I still have to mention that maintaining ORM based data layer can be either beautiful or hell with ORM. The problem is that with ORM, sometimes it's difficult to predict when you going to shoot yourself on the foot. What's your opinion about this? Is it worth the frustrations you're very likely to face? What about the risks of having a completely failed data layer? I've taken as a personal philosophy to never use ORMs on "real" projects, unless explicitly asked by the client or for demonstration purposes. I still have to give Entity Framework a try though.
You should check out XPO from DevExpress.
-
nHibernate is a port of Java's hibernate. It took on a life of it's own a while back, and in some ways it outstrips the Java version (or so I'm told). Basically, it's meant to be a database agnostic ORM, so you describe the data you want from it, and leave it to work out how best to get it. The theory here is that companies write software that they can easily port to other database vendors without requiring changes to the data layer. In all my years developing, I've only twice ported to different database vendors and an ORM was no use because we ported deliberately to target DB specific features (e.g. Oracle Spatial).
I'm not a stalker, I just know things. Oh by the way, you're out of milk.
Forgive your enemies - it messes with their heads
This is not theory! Software companies selling apps targeting DB system independence do indeed exist, even if you never worked for such a company. Several ORMs have DB independency, for example XPO from DevExpress.
-
You should check out XPO from DevExpress.
I don't know if this will be any different from other ORMs on the high level. I beleive the same pitfalls should apply. By reading the main features, I've seen nothing other ORMs don't do, in fact, I don't see significant reason to invest cash on something that is not native of the .net framework, if the .net framework can also deliver such features. Unless there's something really cool about this ORM, it won't change my mind about ORMs... [Edit] Humm... Interesting it supports direct SQL Queries, I can see some potential here...
-
hehe :) I don't think any ORM solution will be good for such thing. If you find one I'd like to hear about it :)
Indeed, and in order to not make everything sound too negative: The database for the application is updated every night from SAP. We left open the option to replace it in the future with a webservice directly into SAP. That's why it does not contain anything specific to the application itself, just the business data. For application specific data there is a second database which is accessed over a second resource access layer. This one is still based on NHibernate and works quite well. After getting the tedious configuration over with, NHibernate actually can be helpful. This part of the application is more the typical website scenario and that is what NHibernate was designed to do.
"I just exchanged opinions with my boss. I went in with mine and came out with his." - me, 2011 ---
I am endeavoring, Madam, to construct a mnemonic memory circuit using stone knives and bearskins - Mr. Spock 1935 and me 2011 -
jschell wrote:
Incorrect/inappropriate use of a tool is not a condemenation of the tool but rather the user.
It's an inappropriate tool for anything of consequence precisely because it leads people to poor design choices. It's single purpose is to save money, not to make great software. I expanded on why I think it's a poor tool for any job in depth in another reply, perhaps you missed it: http://www.codeproject.com/Lounge.aspx?msg=3847223#xx3847223xx[^]
jschell wrote:
However I would certainly love to see an analysis that demonstrates that most applications, large and small, do not show a strong correlation between tasks and data models.
You honestly think most applications are well designed and easy to use? :)
jschell wrote:
Pretty sure that most developers are neither engineers nor designers. Although I have never actually seen a job description that said 'designer' which wasn't exclusively applied to a GUI programmer. And those positions were not architect positions.
My terminology may be incorrect, what I mean is whatever people are calling a systems analyst and designer these days. I mean ultimately someone who is responsible for thinking like the customer and designing the interface (hence business object layer) accordingly.
There is no failure only feedback
John C wrote:
It's an inappropriate tool for anything of consequence precisely because it leads people to poor design choices. It's single purpose is to save money, not to make great software.
I have never worked for a company that mattered where the goal was to "make great software". The goal of companies that "matter" at least for any length of time, is to make money. And obviously one way to make money is to not spend it in the first place. Of course all of that matters if you original conclusion was correct in the first place - that the tool is the problem. The implicit assumptions in your conclusion that if the tool didn't exist that many people would make better software is just wrong. Groups always consist mostly of average people. Thus, by definition, the product is most likely to be average or only slightly better than average. But average doesn't mean stupid. The market place is littered with failed ideas/products which even the average developers manage to reject. And hHibernate (and hibernate) have been around long enough that it seems doubtful that it is being rejected.
John C wrote:
I expanded on why I think it's a poor tool for any job in depth in another reply, perhaps you missed it:
http://www.codeproject.com/Lounge.aspx?msg=3847223#xx3847223xx[^]I read before. Didn't seem to provide any measurable content.
John C wrote:
I mean ultimately someone who is responsible for thinking like the customer and designing the interface (hence business object layer) accordingly.
Far as I know the first would be called a business analyst and the second, depending on the scope of work, an architect or web designer (or gui). The last however would not be responsible for the business layer. The first would be not be responsible for the actual design/implementation. The architect on the other hand would be responsible for all of it. And often with the budget as well. Which means saving money (and time.) Because, again, that is important to businesses.
-
Dominic Pettifer wrote:
Bad UI has got absolutely nothing to do with an ORM
You're right, many bad UI's are bad even without using an ORM. ;)
Dominic Pettifer wrote:
NHibernate DOES NOT code generate a complete application for you
If your business object layer *isn't* essentially your entire application you're doing it badly wrong in this day and age.
Dominic Pettifer wrote:
Nhibernate doesn't just map one table to one class,
....and...? I don't understand what this point has to do with task oriented design. I'm almost wondering if the people replying to my criticism have even *heard* of task oriented design. NHibernate and it's ilk of ORM "solutions" are right in the wheelhouse of the type of software I work on every day and have for well over a decade now. It's something I'm extremely familiar with and in those circles the only people arguing in favor of ORM tools for anything of significance are people who either a) Are ignorant and don't know any better, b) work for a cheap company that doesn't care about the quality of the user experience and just want to save money or c) Use it judiciously for only very minor quick projects where quality and ease of use are not important and time to market is d) care more about their free time away from programming than about quality applications or e) People who *make* orm tools. I'm fairly confident that most developers that use the tools fall into category A or category B.
There is no failure only feedback
John C wrote:
....and...? I don't understand what this point has to do with task oriented design. I'm almost wondering if the people replying to my criticism have even *heard* of task oriented design.
It is your conclusion that by itself this tool leads to poor designs/implementations. That has nothing to do with whether one correctly implements an idiom or not. Matter of fact at one point I researched process control techniques extensively over time for several years. And of the many studies I saw there was never a mention of any tool, of any sort, that specifically either better or worse in terms of impact on software development. Same applies to design idioms. So do you have some evidence to even back your assumption that task oriented design does in fact improve something in a measurable way?
John C wrote:
NHibernate and it's ilk of ORM "solutions" are right in the wheelhouse of the type of software I work on every day and have for well over a decade now. It's something I'm extremely familiar with and in those circles the only people arguing in favor of ORM tools for anything of significance are people who either a) Are ignorant and don't know any better, b) work for a cheap company that doesn't care about the quality of the user experience and just want to save money or c) Use it judiciously for only very minor quick projects where quality and ease of use are not important and time to market is d) care more about their free time away from programming than about quality applications or e) People who *make* orm tools.
Well you have certainly worked in significanly different places than me. In the places I have worked (financial for 10 years and telephony before that) most developers do not know what a ORM tool is. Most developers do not touch databases nor persistent storage. Some are actually incapable of writing minimal SQL much less doing something like creating a database. And very definitely they cannot design persistent storage correctly. And your last points are certainly idealistic. Myself I don't think much about "time to market" specifically but I do care how long it takes me to deliver something because I realize that the longer it takes the more it costs the company in a number of ways. 1. Paying my salary. 2. Lost oppurtunities 3. Loss of recurring revenue And when that is 'better' it means that I am assured
-
n.podbielski wrote:
So you are using nH because it is much more flexible?
Exactly this. And don't get too down about the experience. You just keep doing what you're doing until you run into issues, then you change something. That's the way I eventually got to nH.
Thanks for good words! I'll do that :)
In soviet Russia code debugs You!
-
BubingaMan wrote:
Last time I've checked, when data is retrieved from the database it ends up in the business layer. From there it can go anywhere, under any form.
Wikipedia: "NHibernate's primary feature is mapping from .NET classes to database tables" (emphasis mine) A well designed business layer mirrors the *tasks* that the user needs to accomplish. A code generated business layer off a database mirrors the *data* that the user needs to deal with. Trying to shoehorn a datacentric business layer into a task centric ui layer is problematic to put it mildly. A task oriented app with a carefully, hand designed, business layer that is often entirely divorced from the actual data storage and tables results in happy users that will say the app is so easy to use and they don't have to think about anything to use it because it follows their real world thought processes. Task oriented apps are a thing of beauty, data oriented apps not so much. If you start with a data oriented business layer you end up writing a *lot* of code above the business layer (often in the UI layer) to accomodate all the business rules and tasks the user needs to perform, exactly the wrong place to do it. The lower you can have the tasks and business rules the less code needs to be written above and when it comes to multiple interfaces like web and windows and services you end up replicating that code over and over. Professional programmers who take their craft seriously do not use code generators for anything of consequence.
There is no failure only feedback
John C wrote:
A well designed business layer mirrors the *tasks* that the user needs to accomplish. A code generated business layer off a database mirrors the *data* that the user needs to deal with
I don't see how you can generate your business layer. You could generate entities, used by your business layer, not the business layer itself. FYI: nHibernate does NOT require you to generate anything at all... but just to map entities to tables. You COULD use a generated to do that, but it's not necessary to do so by any means. Besides, I'ld assume (or hope) that the general architecture for line of business software looks like this: - GUI layer (consisting of MVC-type pattern) - (wcf if necessary) - Business Layer - data access layer - database Your business can be anything you want it to be. And most importantly, it can return to your GUI whatever you want it to. For me, my generated entities NEVER leave the business layer. I use DTO's for that. And those DTO's are really not necessarily mapped 1-1 to the entities. I don't know how you design your architecture, but it seems to me that you do not have a real data layer. The way you explain it, it seems as if your data layer IS your business layer.
-
John C wrote:
A well designed business layer mirrors the *tasks* that the user needs to accomplish. A code generated business layer off a database mirrors the *data* that the user needs to deal with
I don't see how you can generate your business layer. You could generate entities, used by your business layer, not the business layer itself. FYI: nHibernate does NOT require you to generate anything at all... but just to map entities to tables. You COULD use a generated to do that, but it's not necessary to do so by any means. Besides, I'ld assume (or hope) that the general architecture for line of business software looks like this: - GUI layer (consisting of MVC-type pattern) - (wcf if necessary) - Business Layer - data access layer - database Your business can be anything you want it to be. And most importantly, it can return to your GUI whatever you want it to. For me, my generated entities NEVER leave the business layer. I use DTO's for that. And those DTO's are really not necessarily mapped 1-1 to the entities. I don't know how you design your architecture, but it seems to me that you do not have a real data layer. The way you explain it, it seems as if your data layer IS your business layer.
-
Jesus man, are you a lawyer? :) The discussion wasn't about how to build an n-tier application.
There is no failure only feedback
John C wrote:
The discussion wasn't about how to build an n-tier application
Indeed, it wasn't. It was about a tool you should be using in the data layer. You seem to maintain however, that whatever data accessing technology you use in the data layer, defines how your GUI and business layer will look like. If that's the case, then you're doing it wrong. n-Tier architecture becomes pointless if your data layer defines your business/gui layer. That's all I'm saying.
-
John C wrote:
The discussion wasn't about how to build an n-tier application
Indeed, it wasn't. It was about a tool you should be using in the data layer. You seem to maintain however, that whatever data accessing technology you use in the data layer, defines how your GUI and business layer will look like. If that's the case, then you're doing it wrong. n-Tier architecture becomes pointless if your data layer defines your business/gui layer. That's all I'm saying.