I have finally decided to go with the Entity Framework since it has the best performance out of all the ORMs. But before I start reading and writing code I just want to know if there are any high traffic websites out there that use ORMs.
Currently, the released version of EF, v1.0 in .NET 3.5, has terrible performance. I did extensive testing and had several long email discussions with Microsoft on the subject over a year ago when it was first released. EF's current efficiency has a LOT to be desired, and in many cases, can generate absolutely atrocious SQL queries that decimate your performance.
Entity Framework v4.0 in .NET 4.0 is a LOT better. They have fixed most, if not all, of the poor SQL generation issues that plague EF v1.0 (including the issues I presented to them a year ago.) Whether EF v4.0 has the best performance is really yet to be seen. It is more complex than LINQ to SQL, as it provides much greater flexibility. As a release version is not yet available, its impossible to say whether EF v4.0 will be the fastest or not.
An objective answer to this would require an objective, unbiased comparison between the major ORM contendors, such as EF, LINQ to SQL, nHibernate (preferably with a LINQ provider), LLBLGen, and even some of the newcommers, such as Telerik's ORM, Subsonic and the like.
As for large-scale, high-volume production systems that use ORM's. I would suggest looking at StackOverflow.com itself, which uses LINQ to SQL. SO has become one of, if not the, top programmer communities on the Internet. Definitely high volume here, and this site performs wonderfully. As for other sites, I couldn't really say. The internal implementation details of most major web applications are generally a mystery. Most uses of ORM's that I know of are also for internal, enterprise systems. Financial systems, health care, etc. Object Databases are also used in the same kinds of systems, although they are much less frequent. I would so some searches for ORM use and high volume web sites.
One thing to note in your search. Make sure the reviews you find are current. The ORM scene has changed a LOT in the last two years. Performance, efficiency, capabilities, RDBMS tuning capability of dynamic SQL, etc. have all improved significantly since ORM's were first created around a decade ago.
I know in one of the podcasts, Jeff mentioned that stackoverflow uses Linq-to-SQL
The really high traffic websites are in fact moving away from SQL databases altogether because with write-heavy workloads common in today's apps, it's nearly impossible to make them scale beyond one machine, ORM or no ORM. This has been dubbed the "NoSQL movement"
However, while this is a very fashionable topic, it's completely irrelevant for sites that don't have thousands of active concurrent users. And worrying about ORM performance is a similar matter: most sites are not in fact "high traffic" enough for an ORM to become a problem (unless grossly misimplemented or -applied).
While not directly addressing which ORM is faster as Ayende (NHibernate author) points out can be very easy to do wrong or at least slant the way you want it to, here are apps out there that are using ORMS as part of their applications.
Twitter is (was?) using Ruby on Rails (RoR) which uses an ORM. The 37 signal guys use RoR for their apps .... I know these aren't .Net but as mentioned by kuoson, L2S is employed by SO and there are alot of people out there using NHibernate like Jeffrey Palermo and Headspring. I wouldn't be surprised to find many recently developed web apps are employing an ORM.
Even if an ORM does cost you a hit on performance, most ORM's allow you to customize the SQL used when necessary. Most suggest using the ORM and then fixing bottlenecks as they arise. Additionally, a good ORM solves so much for you that writing your own DAL is becoming a much tougher sell these days.
jrista is right on. I just want to add that you should seriously consider LINQ to SQL. From both a simplicity and a performance standpoint it is the better technology (for now). It is very fast and reasonably capable out-of-the-box. If you want to further improve LINQ to SQL, check out the PLINQO framework.
PLINQO is a framework that sits around standard LINQ to SQL and adds a ton of features including some very elegant bulk operations and caching features. Best of all PLINQO adapts to changes in your database schema but preserves your custom code. Which is VERY slick and, in my opinion, the most valuable aspect.
Sure, reddit uses parts of SQLAlchemy (for reasons unknown I believe they rewrote most it :/). Most, if not all of the large Django websites use the ORM (including the former Pownce and Curse).
Related
I'd like to learn database applications in C# and I'm about to select some framework. I heard many recommendations of NHibernate, however I haven't decided yet.
Anyway, I'd like to know if there's any real-life example (with sources) of NHibernate in C#, to learn best practices etc.? I know all of them are probably covered in the docs, but working example helps a lot understanding the proper development pattern.
Check out Ayende#Rahien, there's a lot of blog entries on NHibernate there. Another good source is NHibernate Forge. To get you started this would be especially helpful: NHibernate Getting Started Guide. Finally here you can find a downloadable working example of a NHibernate project based on the Northwind database.
The open source project S#arp Architecture is so far the best example I'm aware of for NHibernate:
S#arp Architecture
Even if it feels sometimes a little bit overdesigned, it follows best practices in implementing NHibernate in a multi-tier architecture.
I personally learned a lot about ORMs and good loosely coupled architecture going through
the code of the project.
Another worthwhile article about NHibernate can be found on CodeProject:
NHibernate Best Practices
Real life example: Orchard uses NHibernate, Fluent NHibernate and Linq To NHibernate for data access. It is an opensource CMS build by Microsofties. Source code is available at CodePlex.
NHibernate is a very solid ORM which allows you to create POCO classes, keeping your domain model very clean and allowing easier testability.
Entity Framework is improving rapidly. The UI tools in EF4 are okay for small applications but it is difficult to manage that kind of development with version control, rapidly changing DB schema etc. With EF4 Code First approach (in CTP stage at the moment) EF4 will will be much more attractive.
I have used LLBLGen in past with great success.
For beginners, Webmatrix can get you started very quickly. Check Rob Connery's video on how to use it with testing framework here
As others have said, NHibernate is a solid framework to work with. It's quite mature and has a lot of features that let you control exactly what will happen to your date.
That said if you're just starting out with database programming you may also want to consider LinqToSql. It's not nearly as powerful as NHibernate, and it has been more or less EOLed. However, what you give up in power you gain in simplicity. It will allow you to get a basic database application up and running probably within minutes and allow you to experiment as you first learn. Despite the simplicity of getting your first app up and running it's still powerful enough to be used to build something like Stack Overflow.
Some good Linq to Sql beginner resources:
NerdDinner
ScottGu's series: Using LINQ to SQL (link is to part 9 because that has links to 1 through 8 at the top). Although this one doesn't have an application download (best I can tell) it basically walks you through building an app.
If you have your heart set on learning NHibernate, you can also start with the NerdDinner tutorial linked above and take a look at Ayende's writeup on porting it to NHibernate as well as a series on mapping NerdDinner with NHibernate. There's also a series of articles on using NHibernate in a WPF application (most other tutorials focus on web apps).
Resources:
Ayende's Reviewing NerdDinner and Reviewing NerdDinner: The Select N+1 pitfall
NerdDinner with Fluent NHibernate Part 1 - The domain model
NHibernate and WPF (again, links to part 4 that has link to parts 1 - 3).
One thing I can't emphasize enough is once you get past the initial "cool...I can talk to the DB" phase, grab a trial license for an appropriate profiler (list of profilers at the top) for your platform. It will let you see what exactly your ORM is sending to the DB. It can be very valuable for learning how what you're doing gets translated into SQL as well as troubleshooting bugs you run into.
Regardless of which path you choose you should also take a look at Data Access Practices Using Microsoft .Net: A Nerdly Comparison and Data Development GPS: Guidance for Choosing the Right Data Access Technology for Your Application Today. Although those only cover Microsoft technologies, it'll give you a high level overview of what's available out there and when it may and may not be appropriate for your projects (in the future).
Take a look at NHibernate addins project http://code.google.com/p/unhaddins/
Though this is not real life production example, the sample applications there are pretty close to real life applications | scenarios. The examples there are written by well known and respected programmers and they show some serious OOP and design patterns skills. This is definitely not for beginners.
We are looking into using an ORM and I wanted some opinions/comparisons
The basic criteria we have for an ORM is: Easy to use/configure(short learning curve), flexible, the ability to abstract it away, easy to maintain
Here is a list of what ORM we are looking at and what our initial impressions are
Open Access - seems really easy for simple stuff, but doesn't seem to have a lot of flexibility, cost isn't an issue we already own it
Ling to SQL - looks very simple to use and configure but is missing some functionality
Active Record - NHibernate made simple
SubSonic - looks very feature rich, but haven't really played with it much
here are the ORMs we have looked at and ruled out
Entity is still in beta
NHibernate has far to much of a learning curve (we don't have 3 weeks to delicate to learning it)
I'd say you should take a look at DataObjects.NET (http://www.x-tensive.com). It's feature rich and pretty easy to use. It does, though, absolutely tie you to your object model, as it decides what the database structure should be based on what your object model looks like. That being said, if you want to be able to disregard the existence of the database, it's quite nice. We've used it for years and have had great success.
We currently use SubSonic (2.0.3) and it has been an absolute lifesaver. I cannot stress enough how awesome it is. HOWEVER, we are now looking at switching away from it for various reasons (probably to NHibernate or Entity). Here are my Pros and Cons of it:
Pros:
Very simple to setup and use.
Lots of great & useful, tools and features
Uses the "convention over configuration" philosophy, so very little configuration. It "just works". (As long as you do things the way it wants... :) )
Cons:
Your database design is very tightly coupled to your domain design. Make a change in your DB, and you need to change your code/domain design.
By default, SubSonic uses the ActiveRecord pattern for all data access instead of the Repository pattern, which makes it more difficult to "abstract it away". (Although I believe with v3.0 that you can swap out the default ActiveRecord templates to use the Repository pattern).
Lots of pessimistic rumours flying around about the future of SubSonic. But rumours are just that: Rumours.
For all the paired pennies it may be worth:
If you don't have 3 weeks now to learn your ORM of choice (whichever you choose), you may have to find 3 weeks to learn it later when it doesn't map something exactly how you thought it would.
If you have a model that's moderately complicated, ORM is non-trivial. You'll wind up needing to know how your ORM works so you can tell it to map things the way you want.
Which is all another way of saying "Know thy tools", of course. :)
Most folks will have a smattering of experience with one or two of those, but few will have exposure to all. I recommend a proof-of-concept effort with each of your favorites. Get each one set up, spending no more than n hours per ORM tool (n = however much time you decide is reasonable.) You don't have to implement your entire object model, a functional subset will do.
By the time you're done, you will have worked through the setup and some usage of all of them. You can then write up a post-mortem and the team can decide which has the best pain-to-feature ratio.
Use T4 templates to create your own. There are several established patterns available on the internet especially for T4 templates.
Knowledge of T4 also will allow you to script out items that might have a large scope than macros, but a smaller scope than writing a custom app to generate the script you need.
Hope this helps!
I very much agree with BryCoBat (upvoted). I wanted to also add that if you already own Open Access, then the company very likely has people somewhere internally who are already very comfortable with it, including code examples you look at in your own domain for both trivial and non-trivial tasks. In other words: use what you know.
If you're not using Telerik controls, LINQ to SQL should be the one to select for fast learning - there is huge amount of different tutorials, videos, books in the web.
Assuming that writing nhibernate mapping files is not a big issue....or polluting your domain objects with attributes is not a big issue either....
what are the pros and cons?
is there any fundamental technical issues? What tends to influence peoples choice?
not quite sure what all the tradeoffs are.
The biggest pro of AR is that it gives you a ready-made repository and takes care of session management for you. Either of ActiveRecordBase<T> and ActiveRecordMediator<T> are a gift that you would have ended up assembling yourself under NHibernate. Avoiding the XML mapping is another plus. The AR mapping attributes are simple to use, yet flexible enough to map even fairly 'legacy' databases.
The biggest con of AR is that it actively encourages you to think incorrectly about NHibernate. That is, because the default session management is session-per-call, you get used to the idea that persisted objects are disconnected and have to be Save()d when changes happen. This is not how NHibernate is supposed to work - normally you'd have session-per-unit-of-work or request or thread, and objects would remain connected for the lifecycle of the session, so changes get persisted automatically. If you start off using AR and then figure out you need to switch to session-per-request to make lazy loading work - which is not well explained in the docs - you'll get a nasty surprise when an object you weren't expecting to get saved does when the session flushes.
Bear in mind that the Castle team wrote AR as a complementary product for Castle Monorail, which is a Rails-like framework for .NET. It was designed with this sort of use in mind. It doesn't adapt well to a more layered, decoupled design.
Use it for what it is, but don't think about it as a shortcut to NHibernate. If you want to use NH but avoid mapping files, use NHibernate Attributes or better, Fluent NHibernate.
I found ActiveRecord to be a good piece of kit, and very suitable for the small/medium projects I've used it for. Like Rails, it makes many important decisions for you, which has the effect of keeping you focused you on the meat of the problem.
In my opinion pro's and cons are:
Pros
Lets you focus on problem in hand, because many decisions are made for you.
Includes mature, very usable infrastructure classes (Repository, Validations etc)
Writing AR attributes are faster than writing XML or NHibernate.Mapping.Attributes IMHO.
Good documentation and community support
It's fairly easy to use other NHibernate features with it.
A safe start. You have a get-out clause. You can slowly back into a bespoke NHibernate solution if you hit walls with AR.
Great for domain-first development (generating the db).
You might also want to look up the benefits and drawbacks of the ActiveRecord pattern
Cons
You can't pretend NHibernate isn't there - you still need to learn it.
Might not be so productive if you already have a legacy database to work with.
Not transparent persistence.
In-built mappings are comprehensive, but for some projects you might need to revert to NHibernate mappings in places. I haven't had this problem, but just a thought.
In general, I really like ActiveRecord and it's always been a time saver, mainly because I seem to happily accept the decisions and tools baked into the library, and subsequently spend more time focusing on the problem in hand.
I'd give it a try on a few projects and see what you think.
When I started using NHibernate, I didn't learn about Castle ActiveRecord until I had written my Mapping files and made my classes. At that point, I couldn't visibly discern what Castle Activerecord would give me, so I didn't use it.
The second time I used NHibernate, I simply used myGeneration to make the mapping files and the classes just by having it look at my database. That saved a lot of time by itself, and allowed me to (once again) not worry about Castle Active Record.
In reality, most of your time is going to be spent making the custom queries, and Castle Active Record won't necessarily help with that -- if you were to use myGeneration with NHibernate, you'd bypass most of the work you'd need to do anyway.
Edit: I don't want to seem like a cheerleader for either myGeneration or NHibernate. I just use the tool that allows me to get my work done quickly and easily. The less time I have to spend writing Data Access code, the better. It doesn't mean I can't do it -- but there's little sense in re-inventing the wheel each time you write a new application. Write SQL queries and Stored Procedures where needed, and no where else. If you're doing CRUD operations, an ORM is the way to go.
Edit #2: Castle Active Record may bring more to the table than I realize -- I don't know much other than what's on their website, but if it does bring more to the table, then it would help potential adopters to be able to readily see that on their site.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
I'm shopping for an ORM tool. I'm agonizing over the purchase of either CodeSmith (which is currently available at a substantial discount) versus an ORM tool.
LINQ to SQL is off my list; SubSonic 2.x is off the list (I don't want to invest in that dead end knowing that SubSonic 3.0 is coming. NHibernate seems like overkill as does LLBLGEN. I've only briefly evaluated EF but don't get quickly get a warm and fuzzy feeling from it.
Am I crazy thinking that CodeSmith is a rational alternative to off-the-shelf ORMs? Will CodeSmith pay for itself in other ways?
Please note that I am in no way related to any vendors and this isn't a cheap shot SO question just for the sake of generating product noise! I am looking for honest advice and opinions about CodeSmith as an ORM tool (with its provided, or community available) templates.
In fact, hibernate is a good ORM tool. But it stops there!
Code smith capabilities can be more than just a relational mapping staff! I use code smith to generate some UI forms, business layers (templates), data access layers, patterns, and so on.
But to work with code smith, you may need good experience with system design or use their templates which I don’t like to use but I like as an example.
Code smith approach has one special drawback; you have to design your system considering the database implementation first. Nowadays, in object analysis approach, people success in implementing business logic & entities just before any database implementation – they forget about this.
Decision is hard; I've constantly read important names such as Scott W. Ambler, Kent beck, Robert C. Martin and people from The Pragmatic Programmers series which recommends ORM Tool to speed up development. They said that ORM Tool developers are concerned with all database issues (pooling, connections, database vendor specifics, etc). So when we have to design data access layers we have to consider all these aspects too.
I believe that these ORM tools come along with an overburden. I don't know yet how these tools would behaviour in low budget projects (I mean not good hosting servers or any kind of shared resources).
I’ve seen inexperienced developers not taking this into account as they try to evangelise their beloved tools. But in java projects, hibernate is already a widespread and well-known tool. I have no doubt the great projects has been delivered using this technology but I have seen anyone and again java developers may need to teach us (.net developers) how to build great solutions. (Sorry, we have to admit.)
The only thing I would recommend is to consider your context. Are you doing a new system? You need work in pattern? Have you ever try to consider such code generator and ORM tools altogether?
I do prefer code smith because I generate entire solutions at once, not just data access layer. Code generation is very important and it is not for less that Microsoft has imitated code smith approach in visual studio.net 2008 and so on.
Good luck
Code Smith is not an ORM, it's just a code generator IDE.
You can generate a DAL using code smith based off your database but that would defeat (one of) the purposes of using an ORM which is basically that it generates the DAL dynamically so you don't have to write the code.
If you're really trying to compare the two, then maybe you might get some benefit using code smith because you would have absolute control over the code that gets generated, but I'm not sure that benefit would outweight the drawback of what could turn out to be spending months to write the code smith templates to generate a DAL based off your database.
And then you have to considering what happens when you make a change to your database, you will most likely have to run code smith and build everytime you do so. A good ORM will allow you to configure your database changes in schema, and then it will generate dynamically so you don't have to worry (as much) about making changes to the database.
NHibernate is the way to go. It is an enterprise-grade ORM. And with the convention-based auto-configuration from the FluentNHibernate library, configuration is ridiculously simple if you stick to a single convention (you get to specify the conventions, or there are defaults).
With NHibernate, your domain objects are pure C# objects. No weird base classes. No codegenned files that need to get refreshed every time you decide to make a change.
I use netTiers daily and love it. Documentation for it sucks, but it has been such a time saver for me at the office. A lot of people gripe about the amount of code it produces, but from what I've seen, the code it creates is a lot faster than hand coding much of it. It also generates all the sprocs you will need for your basic CRUD stuff. The access methods it produces are pretty awesome as well, getting by all your unique keys, foreign keys and primary keys.
I think the usage of Codesmith is viable. But you should look into frameworks that use it. Net Tiers is an application framework that can be built upon to knock out a good DAL.
Why would something like LLblgen be overkill ? We use it at work, and after a somewhat steep learning curve, it's very nice :). You should at least give that and nhibernate a try.
Not sure what this has to do with codesmith though, thats a codegenerator, you could roll your own ORM, but since there are already good ones out there, I dont think it's worth the time and effort unless you want to do it for learning purposes.
Go with netTiers and .netMVP. NetTiers is a very nice DAL and .netMVP is a framework I just released to support abstraction at the UI level. :)
http://community.codesmithtools.com/CodeSmith/m/templates/42499.aspx
I used LLblgen several years ago. I hope what I saw has been fixed. We looked at the in-line SQL that was produced and saw, for selecting one row of data with the primary key passed in:
SELECT DISTINCT * FROM TABLE WHERE primark_key_id = #primarykey.
Really, DISTINCT? I always begged to do store procs instead, but what shot down by the project leader. I am not sure what time was saved by writing inefficient code.
I'm currently working on putting together a fairly simple ORM tool to serve as a framework for various web projects for a client. Most of the projects are internal and will not require massive amounts of concurrency and all will go against SQL Server. I've suggested that they go with ORM tools like SubSonic, NHibernate, and a number of other open source projects out there, but for maintainability and flexibility reasons they want to create something custom. So my question is this: What are some features that I should make sure to include in this ORM tool? BTW, I'll be using MyGeneration to do the code generation templates.
For the love of all that's holy (and the women and the children), do everything possible to convince them not to go with a custom O/RM solution. Why are people wanting to re-invent the wheel when there are perfectly-good, open-source wheels already in existence?!?!
If your client isn't interested in OSS because of (real or imagined) perceptions about support, have you considered any of the top-quality commercial third-party ORMs such as LightSpeed that comes with a nice GUI designer tool
(source: mindscape.co.nz)
Mindscape (the company that sells LightSpeed) is a New Zealand company based near where I live, I have met some of the devs there, and I know they are famous for having incredible customer support. And they give you the source code when you buy the software, so you can tweak it any way you like.
You probably don't want to have to roll your own ORM unless you have to and your client is willing to hand over a stupid amount of cash for you to do so.
IMO writing your own OR/M is one the worst design decisions you could ever make. "maintainability and flexibility" are reasons exactly NOT to write your own OR/M.
Please read See 25 Reasons Not To Write Your Own Object Relational Mapper, and see if your client really wants to pay what it costs to build something like NHibernate ($7.6M) or SubSonic ($1.5M). Because, like ChanChan said above, you will end up with something similar to that.
There's a bunch of posts by Davy Brion (an NHibernate committer) who is for some reason also forced to write a custom ORM for a client.
Some of the things he covers are:
Mapping Classes To Tables
Out Of The Box CRUD Functionality
Hydrating Entities
Session Level Cache
Executing Custom Queries
Definately worth checking out, if you MUST go down this path: Build Your Own Data Access Layer Series
You need to go the nHibernate style, in my experience, and have it so that you have some kind of map, between your objects and the database. This allows your objects to have some things that are hard to represent in a database but are easier represented in POCOs.
Generation gets you started, by giving you classes that meet your schema, but if you plan on maintaining anything or testing anything, mapping is pain now for pleasure later.
Subsonic is a great model, and its open source, if you must go generation, use their templates in myGeneration to get a leg up.
BTW: I've done what you are doing, and I ended up with something very similar to subsonic, and now advise my clients to take the subsonic source, and fork it for themselves.
Maybe just maybe, you need badly some "features" that do not exist yet in the existing solutions. Maybe you need something simpler also. 1.5$ for Subsonic is simply outrageous.
Maybe you want to use POCO. Maybe you want to use the stuff easily in a 3 tier scenario.
Maybe you don't want to support ALL RDBMS on the planet, so you can hardcode and optimize the code just for your target. Maybe you want to implement smarter object tracking. Maybe some design decisions made by the existing orms drive you crazy....
I myself am using a custom orm developed by me myself and i, and i am satisfied that i did it. There is no hidden dragon under the carpet, no surprise scenario. My orm does exacty what i want it to do, nothing less, nothing more.
Second level cache
Allows you maintain entities instances in-memory
Automatic dirty-checking
Allows you updates changes in an object without loading it.
Powerful query language
Powerful cascade operation
Powerful primary key generator strategy
ORM framework will pickup best primary key generator strategy according to target database
Support to composite elements
Support to events
onSave, onUpdate and so on
Good documentation and reference books
Support to conversational state
regards,
No-one has mentioned it yet; but go with LLBLGen. You may customise the template as you like, and you may also, obviously, write your own custom code in the generated classes. Buy it. You will never look back, and you will be saying "Thank you silky!" when it consistently works beautifully. (I didn't write it, but I love it). If it doesn't work out for you, you may also say "Damn you silky!". But that's unlikely, however I do offer it as an option.
The only bad thing I noticed about LLBLGen has been the support for switching between Databases/servers on the fly. It doesn't support a feature that I'd like; namely the ability to detect that a given entity you retrieved doesn't "exist" in a new database that you've switched to. But this is a rare case.
I suggest LLBLGen, because I was in the process of writing my own OR/M when I came across it. Never looked back.
Your job as a consultant (sounds like that's what you are) is to leverage your expertise in implementing for your clients a solution that fits their desires with a minimum cost and time investment.
If they want to build and sell an OR/M. The go to town making one. If they want anything else, use one that already exists to get the job done.
If they insist on spending money, buy an existing one (I won't name any, but there exist some good ones that are not free).
Try to use Devart LinqConnect - all of the LINQ to SQL features and wide support of the most popular database servers - Oracle, MySQL, Postgre, SQL Server, and SQLite. Incredible Visual Modeling tool, advanced monitoring tool, high quality support - as a result i've learned it only in three weeks during my project execution.