In a sense NHibernate seems convenient because it leads to less typing, and then propably less errors.
I think NHibernate can be used in every size of application because it is really easy to use (especially with FluentNHibernate) and you it does much work for you like generating SQL
queries, mapping values to objects and so on. Even in typical small applications you need to put a great part of the whole effort on the data persistence layer, so why don't let NHibernate do the work for you?
Best Regards,
Oliver Hanappi
It is tough to judge what you are looking for based on the terseness of your question, as there is really a lot of nuance in an answer to this.
In many ways, as the others here say, it depends on your project and your knowledge of nHibernate. But it also depends on a lot of other factors as well...
If you think your small project might grow into a large project someday that could make a better argument for it as you then have a strong foundation on which to grow.
If your goal is learning nHibernate (or another ORM) then a small project may be the best place to get your feet wet and try it out. (Also try Linq2SQL, and other ORMs as well and go with what you find works the best for you.)
I personally use nHibernate for all of my projects large and small (where possible due to other constraints). But I've also been working with it for a while and a good base of code that I can reuse. So that factors into the time part of an answer. nHibernate has a pretty steep learning curve so if you need something done quick nHibernate may not be optimal.
I hope that helps, if you can refine your question and your goals a little more in your question it will assist the rest of us in getting you some better feedback and ideas to help you.
It depends what you mean by small, and how accomplished you are with Hibernate. I'd find that the extra overhead of getting set up would not make using it a good option on a little project personally. I'd say the same about other frameworks like Spring too, they are far more useful on larger projects with lots of developers.
It's not if you have a strong knowledge of NH, if you have some model generator, if you use some DBMS other than SQL Server.
I think that if you have a DB on SQL server, you're quin in a hurry, you are knowledgeable on LINQ, LINQ2SQL might be a good choice. Fast and RAD.
I agree with Oliver but would add the caveat that it is only easy to use once you know how (and that may take awhile). If you haven't gotten on top of the learning curve and need a simple app, NHib will slow you down; otherwise use it on anything that isn't completely trivial or a throw away! So your simple but effective app has one more sound piece of infrastructure as it scales and adapts to requirement changes.
HTH,
Berryl
Related
I am starting to delve into the realm of ORMs, particularly NHibernate in developing .NET data-aware applications. I must say that the learning curve is pretty steep and that a lot of things should be noted. Apparently, it actually changes the way you do data-aware applications, manner of coding, development and just about everything.
Anyway, I want to ask if you do set some parameters when deciding to USE or NOT TO USE ORMs in your applications? How do you decide then the approach that one needs to make it valuable to your organization?
The organization which I work for now apparently has made a lot of SQL and Data Access thing running through back end and I must say that these class/methods/procedures have successfully performed their tasks of providing the data which is needed and when it is needed. I think it would be a tremendous effort just to map some of this into ORM and derive the same business value that the company has for the last few years.
Nevertheless, I know that ORM paves the way for applications to talk with database servers, if properly implemented. I must admit that I am at a learning stage and that I would possibly need all the help, resources and the guidance to make this transition. I was also thinking of buying the book from Manning but I feel that with so much changes to NHibernate, the book may be a bit outdated. Perhaps waiting for the Packt book on NHibernate (release on May 2010??) would help me better get up and running.
Kindly share your thoughts. By the way, if you could also point me in a small sample web app which uses NHibernate + Visual Web Developer 2008 Express and SQL Server, that would be highly appreciated.
Thanks.
For me, the short of it is the following:
If you don't use an established ORM, and you develop correctly (meaning you refactor out duplication and look to simplify where you can), you'll wind up building your own ORM through the evolution of your data access layer.
The question then becomes:
"Do I want my developers spending time learning the idiosyncrasies of my home-grown ORM or learning those of a well-documented and well-tested ORM?"
Furthermore:
"If I'm hiring a new developer, wouldn't it be nicer to bring in a developer that knows the established ORM tool we're using rather than having to train someone up on this thing I built?"
I use NHibernate, particularly Fluent - and it's great; if given the choice, I wouldn't develop on an RDBMS any other way.
To be successful with an ORM you must make sure to normalize correctly, and use the database for it's designed purpose, storing data.
I don't use an orm when:
I don't use a relation database (Relational databases are not the best choice of database for every application)
The database is has a very small amount of tables. (I might need less code without an orm)
I use a very simple database that can map to code with simple naming
conventions. (Mapping to dumb DTO classes and all queries like select * from tablename where id=#id)
Learning a good orm is worth the time and effort, it will save you writing a lot of code when you use relational databases a lot.
You can find example apps/tutorials/video's about NHibernate on with stackoverflow search. There is another book in progress by manning, maybe it's possible to read it with the early access program.
I am really torn right now between using O/R mappers or just sticking to traditional data access. For some reason, every time I bring up O/R mappers, fellow developers cringe and speak about performance issues or how they're just bad in general. What am I missing here? I'm looking at LINQ to SQL and Microsoft Entity Framework. Is there any basis to any of these claims? What kind of things do I have to compromise if I want to use an O/R mapper. Thanks.
This will seem like an unrelated answer at first, but: one of my side interests is WWII-era fighter planes. All of the combatant nations (US, Great Britain, Germany, USSR, Japan etc.) built a bunch of different fighters during the war. Some of them used radial engines (P47, Corsair, FW-190, Zero); some used inline liquid-cooled engines (Bf-109, Mustang, Yak-7, Spitfire); and some used two engines instead of one (P38, Do-335). Some used machine guns, some used cannons, and some used both. Some were even made out of plywood, if you can imagine.
In the end, they all went really really fast, and in the hands of a competent, experienced pilot, they would shoot your rookie ass down in a heartbeat. I don't imagine many pilots flew around thinking "oh, that idiot is flying something with a radial engine - I don't have to worry about him at all". Everyone understood that there were many different ways of achieving the ultimate goal, and each approach had its particular advantages and disadvantages, depending on the circumstances.
The debate between ORM and traditional data access is just like this, and it behooves any programmer to become competent with both approaches, and choose the option that is right for the job at hand.
I struggled with this decision for a long time. I think I was hesitant for two primary reasons. First, O/R mappers represented a lack of control over what was happening in a critical part of the app and, second, because so many times I've been disappointed by solutions that are awesome for the 90% case but miserable for the last 10%. Everything works for select * from authors, of course, but when you crank up the complexity and have a high-volume, critical system and your career is on the line, you feel you need to have complete control to tune every query pattern and byte over the wire. Most developers, including me, get frustrated the first time the tool fails us, and we cannot do what we need to do, or our need deviates from the established pattern supported by the tool. I'll probably get flamed for mentioning specific flaws in tools, so I'll leave it at that.
Fortunately, Anderson Imes finally convinced me to try CodeSmith with the netTiers template. (No, I don't work for them.) After more than a year using this, I can't believe we didn't do it sooner. My team uses Visual Studio DB Pro, and on every check-in our continuous integration build drops out a new set of data access layer assemblies. This handles all the common, low risk stuff automatically, yet we can still write custom sprocs for the tricky bits and have them included as methods on the generated classes, and we can customize the templates for the generated code as well. I highly recommend this approach. There may be other tools that allow this level of control as well, and there is a newer CodeSmith template called PLINQO that uses LINQ to SQL under the hood. We haven't that yet examined (haven't needed to), but this overall approach has a lot of merit.
Jerry
O/RM tools designed to perform very well in most situations. It will cache entities for you, it will execute queries in bulks, it has a very low level optimised access to objects which is way faster than manually assigning values to properties, they give you a very easy way to incorporate variations of aspect oriented programming using modern technics like interceptors, it will manage entity state for you and help resolve conflicts and many more.
Now cons of this approach usually lies in lack of understanding of how things work on a very low level. Most classic problem is "SELECT N+1" (link).
I've been working with NHibernate for 2.5 years now, and I'm still discovering something new about it almost on a daily basis...
Good. In most cases.
The productivity benefit of using an ORM, will in most case outweigh the loss of control over how the data is accessed.
There are not that many who would avoid C#, in order to program is MSIL or Assembly, although that would give them more control.
The problem that i see with a lot of OR mappers is that you get bloated domain objects, which are usually highly coupled with the rest of your data access framework. Our developers cringe at that as well :) It's just harder to port these object to another data access technology. If you use L2S, you can take a look at the generated code. It looks like a complete mess. NHibernate is probably one of the best at this. Your entities are completely unaware of your data access layer, if you design them right.
It really depends on the situation.
I went from a company that used a tweaked out ORM to a company that did not use a ORM and wrote SQL queries all the time. When I asked about using an ORM to simplify the code, I got that blank look in the face followed by all the negatives of it:
Its High Bloat
you don't have fine control over your queries and execute unnecessary ones
there is a heavy object to table mapping
its not dry code because you have to repeat your self
on an on
Well, after working there for a few weeks, I had noticed that:
we had several queries that were almost identical, and alot of times if there was a bug, only a handful would get fixed
instead of caching common tables queries, we would end up reading a table multiple times.
We were repeating our selves all over the place
We had several levels of skill level, so some queries were not written the most efficiently.
After I pointed most of this out, they wrote a "DBO" because the didn't want to call it an ORM. They decided to write one from scratch instead of tweaking out one.
Also, alot of the arguments come from ignorance against ORM's I feel. Every ORM that I have seen allows for custom queries, and even following the ORM's conventions, you can write very complex and detailed queries and normally are more human readable. Also, they tend to be very DRY, You give them your schema, and they figure the rest out, down to relationship mapping.
Modern ORM's have a lot of tools to help you out, like migration scripts, multiple DB types accessed to the same objects so you can leverage advantages of both NOSQL and SQL DB's. But you have to pick the right ORM for your project if your going to use one.
I first got into ORM mapping and Data Access Layers from reading Rockford Lhotka's book, C# business objects. He's spent years working on a framework for DAL's. While his framework out of the box is quite bloated and in some cases, overkill, he has some excellent ideas. I highly recommend the book for anyone looking at ORM mappers. I was influenced by his book enough to take away a lot of his ideas and build them into my own framework and code generation.
There is no simple answer to this since each ORM provider will have it's own particular pluses and minuses. Some ORM solutions are more flexible than others. The onus is on the developer to understand these before using one.
However, take LinqToSql - if you are sure you are not going to need to switch away from SQL Server then this solves a lot of the common problems seen in ORM mappers. It allows you to easily add stored procedures (as static methods), so you aren't just limited to generated SQL. It uses deferred execution, so that you can chain queries together efficiently. It uses partial classes to allow you to easily add custom logic to generated classes without needing to worry about what happens when you re-generate them. There is also nothing stopping you using LINQ to create your own, abstracted DAL - it just speeds up the process. The main, thing, though is that it alleviates the tedium and time required to create basic CRUD layer.
But there are downsides, too. There will be a tight coupling between your tables and classes, there will be a slight performance drop, you may occasionally generate queries that are not as efficient as you expected. And you are tied in to SQL Server (though some other ORM technlogies are database agnostic).
As I said, the main thing is to be aware of the pros and cons before pinning your colours to a particular methodology.
I'm considering adopting .nettiers for a new project as it seems to provide a lot of functionality I could use.
Is anybody using it in anger (I'm getting the feeling it hasn't got the following it once had) and if so, what are your perceptions of it?
Also, I can't find any comparative performance metrics against things like SubSonic. Anybody have any strong feelings about its performance and scalability?
Many thanks
Tony
When I used NetTiers, I was very happy with it to an extent. You really need to learn the best ways to use it. There were definitely some weird bugs, things that had arbitrary limits and so forth. You have to be careful with it but it can definitely improve your productivity if you learn. I know CodeSmith has started putting more resoucres in it. The version 2.3 might be very solid. Although, the latest current stable version may be pretty solid, I haven't used it in awhile.
Honestly, at this point I prefer LLBLGen. I did try SubSonic a couple times. I didn't run into major bugs but I ended up switching, in both cases, to NetTiers. With SubSonic I felt that I was just typing out way too many string literals and it just didn't feel as mature as other alternatives.
Look at this. It provides you with a good X vs Y comparison between the two of them.
A Key point that i always revise when selecting a framework to work with is:
Will this Simplify, Make me more Productive, if you answer "Yes of course" to this, it doesnt matter what other benchmarks say, even if it's 10% slower in running than SubSonic or even faster, you should go with the framework you develop the fastest and most that you are the most comfy in.
I had some time this afternoon to run a head to head comparison between netTiers and SubSonic.
I used code generated using SubStage (part of the SubSonic 2.1 release) and I used RepositoryRecord as my base class.
I ran the same test against the same database using code generated by .netTiers 2.2
The test was a derivative of the one that Rob Conery used in his post:
http://blog.wekeroad.com/blog/subsonic-scaling/
When i say derivative, I mean I just wrote 100,000 records into the database.
I repeated each test on the same PC three times.
I found that .netTiers accomplished the task in 90 seconds.
Subsonic completed it in 104 seconds.
There was no more than a one second deviation from these averages.
Look at this. It provides you with a
good X vs Y comparison between the two
of them
Thanks - I've already read this post before, but it's over two years old and both projects have advanced a great deal since then.
Asking whether or not a framework will make me more productive or not is a very important consideration, but it's not the only one.
Another for me has to be "am I going to lose potential productivity gains because the framework I adopt is full of bugs, nasty to use, or just a PIA?" which is why I asked if people are using it in anger and what their experience is.
If .nettiers is 10% slower than subsonic, but gives me a whole bunch more features (such as better validation, business rule enforcement etc) then I can live with that. If its ten times slower, then I'd not consider it.
Many thanks
Tony
I've been successful with writing my own SQL access code with a combination of stored procedures and parameterized queries and a little wrapper library I've written to minimize the ADO.NET grunge. This has all worked very well for me in the past and I've been pretty productive with it.
I'm heading into a new project--should I put my old school stuff behind me and dig into an ORM-based solution? (I know there are vast high-concepts differences between NHibernate and EF--I don't want to get into that here. For the sake of argument, let's even lump LINQ with the old-school alternatives.) I'm looking for advice on the real-world application of ORM type stuff against what I know (and know pretty well).
Old-school ADO.NET code or ORM? I'm sure there is a curve--does the curve have an ROI that makes things worthwhile? I'm anxious and willing to learn, but do have a deadline.
I find that LINQ to SQL is much, much faster when I'm prototyping code. It just blows away any other method when I need something now.
But there is a cost. Compared to hand-rolled stored procs, LINQ is slow. Especially if you aren't very careful as seemingly minor changes can suddenly make a single turn into 1+N queries.
My recommendation. Use LINQ to SQL at first, then swtich to procs if you aren't getting the performance you need.
A good question but a very controversial topic.
This blog post from Frans Bouma from a few years back citing the pros of dynamic SQL (implying ORMs) over stored procedures sparked quite the fiery flame war.
There was a great discussion on this topic at DevTeach in Montreal. If you go to this URL: http://www.dotnetrocks.com/default.aspx?showNum=240 you will be able to hear two experts in the field (Ted Neward and Oren Eini) discuss the pros and cons of each approach. Probably the best answer you will find on a subject that has no real definite answer.
I've been quite used to working on small projects which I coded with 1,000 lines or less (pong, tetris, simple 3d games, etc). However as my abilities in programming are increasing, my organization isn't. I seem to be making everything dependent on one one another, so it's very hard for me to change the implementation of something.
Any ideas for keeping my code organized and being able to tackle large projects?
whiteboards are your best friends
prototype designs (not necessarily working prototypes, use notecards or other methods)
plan first! dont code until you know your requirements/goals
Sketch out an architectural design ahead of time. It doesn't have to be too detailed, but imagine how you want things to fit together in general terms.
Read into refactoring first (made famous by Martin Fowler).
By learning refactoring, you can learn how to write code which is easy to change, readable, and simplified.
I would suggest not to learn design patterns until you understand refactoring first. With refactoring, you can understand the themes of clean and readable code. Once you understand refactoring, read on to design patterns. Design patterns is very useful when you need to write more complex designs.
Use of design patterns is a good first step.
Also, spend a little time writing good documentation regarding system architecture and requirements for the application.
Using source control will help if you are not already doing this.
Look for libraries that may do want you want before you decide to roll your own.