We Keep Coding

.Net ORM with the fastest learning curve?

A little briefing first; I've been a Delphi person for years, and been away from C# for two years. The last thing I've done in C# was a mid scale DB app with my own custom DAL. Ie, I had coded my own functions to retrieve data as list, functions to append data and so on. Now I am offered a small to mid scale project using C# WinForms and SQL Server, and there's a deadline which is about 2 or 3 weeks. Note that I forgot LINQ syntax and lots of things.
Now, which ORM would be easiest and fastest to learn? I can cope with not using business abstraction layer if need be, to gain time that is. I need something that'll ease manual labour. Thanks in advance.

For quick-to-implement etc, I'd look at LINQ-to-SQL; the jury is still out on who considers it to be full ORM, but tbh I don't care; it lets me map my data quickly, simply, conveniently and safely, with decent IDE/language support. The LINQ you generally need is pretty minimal... from, where, select, etc. And setting it up is just a case of telling the designer about the tables/columns vs clases/properties.

If I were you I would go for Entity framework. It's pretty simple,easy to implement, efficient and successful ORM tool. You can use LINQ as well in the entity framework while retrieving the data.

As a recent ex-Delphi developer I've been amazed with using MyGeneration to generate basic DAL/BLL classes from an existing database, via custom templates. Takes a lot of the drudgery out of the task.
I've also seen some high praise for Business Logic Toolkit for .NET. Its clean and simple architecture and small learning curve makes it very attractive. Not really ORM, but will get you up and running quickly.
If you search for the terms C#/ORM here, you will find lots of lively and interesting debates!
Choosing Database and ORM for a .NET project
Some suggestions on which .NET ORM to look at learning
https://stackoverflow.com/questions/132676/which-orm-for-net-would-you-recommend
https://stackoverflow.com/questions/146087/best-performing-orm-for-net

If you don't mind a commercial product, Lightspeed is almost too good to be true. I've used it for about 6 months now and it has helped me in every way possible, from designing the model using a graphical tool, to migrations when upgrading, updating the database with a single click, good unit testing, easy custom extending, validation, etc. At least try out the free version!

I have a project on .NET and MySQL. I've learned Devart LinqConnect in three weeks to complete it. All of LINQ functionality, wide support of MySQL, high quality support - like this product.

Is it foolish of me not to use NHibernate for my project?

I am working on a .NET web application that uses an SQL Server database with approximatly 20 to 30 tables.
Most tables will be included in the .NET solution as class.
I have written my own data access layer to read the objects from, and write them to the database.
The whole thing is consist of just a few classes and very few lines of code en uses generics and reflection to find out what SQL and parameters to use.
Now, such thing could be done by using NHibernate (or similair framework) and some co-workers claim that is foolish of me not to use it.
My main argument for not using it is that i want maximum control over my application, know exactly what everything does and how everything works, even if that costs me more development time.
I also dont like the fact i have to map my database in XML files (my own solution lets me map it in the entity class files).
So, what i would like to hear from you is, is it really stupid to not use NHibernate in this situation?
Am i really being ignorant or is it not such a strange idea to use my own solution?

I think these days there really isn't any reason to roll your own persistence framework since there are so many good choices out there. You don't have to use NHibernate (though it is a good choice) but I would seriously consider using something that is well tested and established in the industry as it will tend to perform better and have less bugs that something you write yourself.

It probably is foolish to write your own classes instead of using NHibernate, but it's less foolish to continue using your own classes, given that you've already written them. Maybe.

I won't call you foolish because I've done exactly the same thing in the past. Then I started using NHibernate and wondered why the hell I rolled my own. It's good, give it a go.

You have several possibilities that are probably better than you reinventing the wheel. Let me name two most likely choices:
Use Entity Framework for your DAL+DAO. This will make your classes (that you've already written) obsolete, since EF will create their own and you'll get up to date with latest language capabilities and technologies.
Use Fluent NHibernate so you don't have to work with XML mappings. This way you'll keep your business layer object classes you've written and avoid tedious NHibernation XML files. It's all C#.
Your way of thinking is good. You want control. That's fine. But using your own DAL is a bit foolish these days, because you are basically reinventing the wheel, plus you'll have not tested/buggy code that will take considerable time to develop+test+debug.
If I were you, I'd go with the #2 option, since I've done option #1 and I know I had to customize lots of things to make EF work as it should. EF will be ready with V2.

People tend to use frameworks that are already written because, well, they're already written (and tested).
But there IS merit to rolling your own. Only you and your colleagues can make assumptions about your domain. A generic framework like NHibernate cannot make many assumptions, because that wouldn't make it very universal.
When you roll your own, you can bake these assumptions into your framework, to make a more streamlined, natural API. That said, if you were starting over I would have suggested taking an existing framework and wrapping it to better suit your needs. But since you already have something and it works for you, I'm not sure that I would suggest swapping it out for something else.

It depends on what they mean by "foolish."
If by "foolish" they mean you shouldn't have written your persistence layer in the first place, they're probably right, but that's crying over spilled milk.
If by "foolish" they mean you should rewrite all your existing code to use another framework (like NHibernate) when it's already working with yours, they're probably wrong (although there's something to be said for # of bugs in NHibernate vs likely # of bugs in yours).
If by "foolish" they mean the entire team knows NHibernate cold, and it's already used in the rest of your code, so by using your framework you're making it harder on the team, they're absolutely right, and you should probably refactor the code in NHibernate as soon as possible, before any more code gets locked in to your framework.
If by "foolish" they mean no one there really knows NHibernate, they just like it, then... nobody wins. They're being fussy, you implemented a framework you didn't have to... let's call it a tie.
All of that said, everyone should write a persistence framework or three. Those probably shouldn't end up in anything that ships, but it's a good exercise. The only mistake you made was tying code the team had to maintain into your good exercise.

There are many good persistence tools out there that are well tested and have proven performance (NHibernate, Linq to entities, LLBL Gen Pro). If your needs are very different from the normal persistence frameworks that exist then I would roll my own. I would want to take advantage of the testing and optimizations of an existing tool if at all possible, however.
That being said, I might also roll my own if I wanted to have the experience of building my own ORM tool and was willing to live with the downsides (not as well tested or optimized as tools that have been around for years, speed to market).

Making your own solution, especially when it seems to work fine and be as simple as you say, is neither ignorant nor strange. There are lots of situations where it's better to do that than to add a dependency on a separate project like nHibernate.
That said, there are of course also a lot of situations where the complete opposite is true. :)
It really depends on your project and team. If you are developing an enterprise application that will eventually be supported by someone else, sticking to industry standards might be a good idea even if it means a bit more work up front.

All of the answers here are great, but I am really surprised that nobody has mentioned Castle ActiveRecord, it sounds very similar to what your framework does and really simplifies the interface to NHibernate. It's one of the patterns that made Ruby on Rails so popular after all!
Ayende Rahien (one of the principal NH developers) gave a GREAT presentation on ActiveRecord at Oredev a few years ago which I highly recommend: http://www.viddler.com/explore/oredev/videos/89

I think that it is a matter of balance of control. You say that you want control and you don't want mappings. If this control comes at the cost that there is an increased development and maintenance cost and that it takes longer to produce working code, then it is a problem.
I personally don't see a problem in rolling a framework as long as it simplifies a repetitive task and makes development more productive and code more stable due to less room for interpretation. We have rolled our own framework, that includes a persistence/data access implementation. Our reasons for doing it, though, were specific. In this case, it was to work within a DDD environment that was much closer to what Evans describes than what most off the shelf products were providing.
I think the difference is, though, that we understood that there was an upfront cost and that it would eventually balance itself out through savings in development time in the future. Of course, if you are writing code that you manually have to manage connections, map data, etc., you are probably going down the wrong path. At the very least, you could be using something like Enterprise Library to help you manage the tedium of connectivity and command construction. But, I also think, that if you have no reuse - nothing that is a "framework" type of implementation that you can abstract and apply to other projects, then you are creating a maintenance nightmare and time sink that you will be the sole owner of.

We were also using our own Data Access Layer and entity classes. We also had a code generator who used to generate all this classes for us. But now we are using Entity Framework and we are more then happy.
Simple advise : Start learning nHibernate or whatever you prefer and start using it in your next project.

Entity Spaces - http://www.entityspaces.net/Portal/Default.aspx
is also a good tool.

I ended up using Fluent NHibernate for the job.
All my entity classes were generated with ActiveRecordGenerator (http://code.google.com/p/active-record-gen/)

.Net Logger (Write your own vs log4net/enterprise logger/nlog etc.)

I work for an IT department with about 50+ developers. It used to be about 100+ developers but was cut because of the recession.
When our department was bigger there was an ambitious effort made to set up a special architecture group.
One thing this group decided to do was create our own internal logger. They thought it was such a simple task that we could spend recources and do it ourselves. Now we are having issues with performance and difficulty viewing the logs generated and some employees are frustrated that we are spending recources on infrastructure stuff like this instead of focusing on serving our business and using stuff that already exists like log4net or Enterprise Logger.
Can you assist me in listing up reasons why you should not create your own .net logger.
Also reasons for why you should are welcome to get a fair point of view :)

In my last job, almost all the infrastructure was written by us instead of using some of-the-shelf products. (and by "all the infrastructure" I mean ALL of it - Logging, Messaging, Database, Containers of so on).
One of the biggest disadvantages of it was that it made us spend most of our time working on the things that are irrelevant to the end-user instead of adding more features.
from that job I've learned to always focus on the things your product was meant to solve. is your company developing loggers? will the quality of your logger influence your customer more than another feature? I don't think so.
You have a limited budget and manpower - use it wisely. Don't reinvent the wheel. I'm sure that your company and your customers will benefit if you'll focus your attention on things that they need.
in my current project I'm using NHibernate as ORM framework instead of an in-house one that is in use in other projects. instead of fixing bugs in the old ORM framework, my focus is on the main roadmap of the project. furthermore, NHibernate has it's own roadmap which means that additional features will come without much resources from my company.

I would take a different approach. How about first introducing a common interface to your own library such as Common Infrastructure Libraries (http://netcommon.sourceforge.net/). Then you can gradually move all projects over to that interface and if your own library is not up to the job for large projects then simply switch over to one of the open source frameworks (or even a commercial solution).
HTH
Alex

I use a custom logging API that uses a provider model design, that allows an external logging framework to be plugged in. I have developed providers for Log4Net, EntLib and the System.Diagnostics.Trace loggers.
This is essentially the same concept as the Common Infrastructure Libraries.
This means that internal developments do not have an explicit dependency on an external logging framework, yet you can still benefit from all the features of your favorite logging framework. In practice we usually use Log4Net except for customers who are already using EntLib.

It cost money.
It was done so many time before.
You are not as special as you think. If you are, then do something about it.
Maybe you are not as smart as you think.
Are you over staffed? Yet?

I disagree with those who see people reinventing wheels everywhere. A wheel could be a database server, an operating system or a programming language. However things like a ORM framework or this log4net thing aren't in the market enough time to be considered wheels.
Many of these products have a short life cycle, they are replaced by new approaches, just consider how many ORM frameworks have you seen, and then comes Microsoft and launches LINQ.
Logging is not a solid discipline you can learn and it is very platform dependent.
So considering using a logging framework which could come obsolete (log4net vs nlog), wasting your time learning it, does not exclude the option of build your own logging.
I have done this with ORM mapping, for me has been better building a few ORM classes than learning nHybernate.

I wrote my own one because I thought (A) it is based on a TraceListener which is a standard .NET class and (B) it is little and simple to use and maybe because I wanted to write one anyway.
But now I am using NLog in my new projects and replacing it in some old ones!
Am I wrong? Both works for me fine and the reason for using NLog for me was that I wanted a feature that needed an almost rewriting of my custom TraceListener. It turned out a 1 or 2 hour tutorial with a sample app was cheaper for me. This is not a universal situation; but helps with having a more clear image about logging problems.

if your logging solution has such special requirements that an off the shelf solution doesn't work, than maybe making a custom version might be worthwhile.
If this is the argument though, one could also consider downloading an opensource framework and try to customize it.

Is Telerik openaccess ORM worth learning?

I have just won 1 Telerik Premium Collection for .NET Developer with subscription (lucky me!) and was wondering whether the OpenAccess ORM is worth learning? Has anyone thrown away their open source variant and are now using the Telerik ORM tools instead?
Are there any benefits from using the Telerik ORM tools instead of an open source variant?
Any thought suggestions?
BTW I can't wait to start using their RadControls for ASP.NET AJAX!!

I'm a happy telerik customer for more than 5 years. I used their ORM only in one solution and never used an open source ORM.
Throw away the existing one?
NO - if you have no problems and the thing does what it should do I wouldn't change.
That has nothing to do with quality or other aspects of telerik ORM.
It's just a matter of fact that using a new product means to learn new things, solve some solved things again in a different way and so on.
BUT - if you have problems (or must make compromises) with your current product it's sure worth to give it a try.
Without knowing other ORMs I have one clear point why I would try telerik ORM.
It's their (telerik's) outstanding support.
None of my other vendors offers / does what telerik does.
Simply take a look at their forums http://www.telerik.com/community/forums.aspx and you'll see what I mean.
You have a problem - they solve it; and that with very fast response times.
And that's a point you should think about when making a decision about ORM (or any other kind of product).

This is an older post, but I thought I would weigh in.
We recently started using Telerik's SiteFinity product for a client website. It is a very good, developer-oriented tool for creating a web content system without the size or expense of SharePoint or something similar.
We also went with a Cloud solution as Telerik's ORM supports Azure, so thus so does SiteFinity - which uses OpenAccess (ORM) to communicate with its database.
I was very impressed with the speed and flexibility of it all, being my first Cloud (Azure) development project. Telerik's customer support and personal attention is beyond reproach. I have been using Telerik products for years and was not surprised how well it worked.
Two days before the site was to go live everything bombed with a very inexplicable .Net error. As it turns out Microsoft announced they were upgrading their Azure SQL servers starting July, 2011: "This upgrade is also significant in that it represents a big first step towards providing a common base and feature set between the cloud SQL Azure service and our upcoming release of SQL Server Code Name 'Denali'."
(http://blogs.msdn.com/b/windowsazure/archive/2011/07/13/announcing-sql-azure-july-2011-service-release.aspx)
By its very nature, Cloud servers are upgraded and moved around behind the scenes so you don't have to mess with it. OpenAccess failed to take this into account however, and when our SQL Azure server group was upgraded OpenAccess failed to recognize its version and bombed.
Telerik, of course, was very quick about releasing a patch - but it still took them a few days. We couldn't wait that long, unfortunately, having already lost quite a bit of time just trying to figure out what was going on. The practical result was that I got to work nonstop for two days with no sleep to move the whole thing into a regular .Net solution with Entity Framework 4 as the ORM.
So to answer the question: Is Telerik ORM worth learning and / or better than an open source solution? I agree with the above statement that if you already have an open source solution, it is working well, has good performance, and is intuitive to develop against - absolutely stick with that.
The value of open source is the community that supports it and your ability to make changes to the underlying system if need be. Had my project been based on an open source ORM, I could have changed the code to default to the most recent version of SQL if it finds it is working with a version higher, and problem solved - sleep had.
The value of a product like OpenAccess ORM is that it is in competition with other products, open source or otherwise, and it has to: Perform Well, be customer oriented, have a manual (very important), and be easier than doing it yourself or learn an open source system that may or may not be very intuitive.
Throw in that Telerik's support is top notch, and I would say you could do worse - as long as you are willing to give up some control and have to wait for upgrades / patches to handle things like I described above.

First off I want you to know that I am not Telerik evangelist...
We did moved away from Telerik's ASP.NET AJAX controls only because we desired greater control over the look and feel of our UI (we still use the controls for quick internal solutions), but I must say their products are excellent given the right conditions. Our web product team started to use the Open Access ORM for our solutions and honestly we never looked back. The first reason that comes to mind to choose a Telerik solution is grade A support which has never failed to provide a resolution to a problem regarding any of their solutions with in 24hrs usually including sample code... Although I can usually dig through blogs for hours to find solutions for most of my issues regarding Microsoft technology I must say it is nice to have support when we need it.

I would certainly recommend using the Telerik Open access ORM. I have used Telerik products (eg telerik Ajax/Silverlight) for a number of years and they are best in class and the technical support is second to none. The company makes money by providing software that works.
Unfortunately this does not apply to open source since by definition anything can changed without proper control. All it needs is one duff developer and an entire suite can be rendered useless.
In order to use the products correctly, swiftly, and efficiently, it is necessary to be a highly competent web developer.

I'm one of those people that won a license at a users group meeting. Thankfully I got to experience how crappy this software is without paying for it.
I never got to test the ORM capabilities because the Visual Studio integration failed. Any click on the Telerik menu in VS threw an exception. And the VS item template that was supposed to be installed was not there, so I couldn't even begin to test the functionality.
Don't be fooled by the pretty designer screenshots, they can't even get the installer to work correctly.

Compare and Contrast NHibernate and OpenAccess from Telerik

Have you used the OpenAccess ORM from Telerik? How does it compare to NHibernate? When should I consider using it over NHibernate?

I'm wondering the same thing myself. On one hand, there's NH with its free, open-source self, but with limited support options. On the other, a fairly new addition to a well-known tool provider's box, OA.
OA costs money, but you get support. NH is free, but support has been known at least in my brief experience to be limited and slow in coming.
I think both are likely fine products. I've decided to give OA a try since I am already a user of Telerik's tools. OA and its support are being paid for anyway.
NH uses plain classes and object with no decorations on the class properties whatsoever. OA requires decorations (nicely generated by the OA Visual Studio GUI).
NH requires a "session" in which to do a unit of work with the database; OA calls it "scope". Both use "transaction".
OA has integration with Visual Studio and can both forward- and reverse-map to and from a database. Forward mapping is so you can design your classes and then "push" those into the database for persistence. The "reverse" is for you "domain model" developers which is what I prefer.
OA is definitely undergoing some major updates as Telerik plays "catch up" per its recent acquisition and release of OpenAccess, formerly owned by Vanatec (out of Germany).
As far as an "ease of use" and "performance / scalability" standpoint, I wish I knew where each stood. I'm sure someone out there could put together an honest test between the two and make those determinations.
One thing I like about NH is the available templates to generate the needed code not just for the "dumb" business objects (which is all OA generates now), but for a BLL and DLL. After much conversation with Telerik, I have the impression they plan for more code-generating options so OA is more useful out of the box.
Hope this helps! Someone please try to get some stats on the performance issues.

I've not used it but one benefit obvious to me, is OpenAccess is supported by Telerik, where as nHibernate is supported by the community. Depending on your company this can be a deciding factor if your ready to embrace open source solutions with no guarentee of support.
Edit
For the record I am a big supporter of nHibernate, and open source in general. I have been using nHibernate for the last six months, using it for all new work in our web application. For my current company it is a good fit (Startups love free).
However, my previous employeer, would have had a very difficult time accepting a community supported component as a core piece of their infrastructure. This is perfectly reasonable as these companies' web sites are their sole source of revenue. Would you want to stake your entire business on software that has no accountability associated with it? Some people wouldn't want to take that risk on.
Personally I have found the support for nHibernate to be on par and even better with some commercial vendors.
My point is not to bash OSS, but to highlight one benefit of using software that has a coporate backing, with a fully staffed and dedicated support channel.

One more reason: Currently OpenAccess has better performance characteristics, if you need fast ORM for your project it will be a better choice. See ORM benchmarks for details.

I would say nHibernate is free and OpenAccess is $399. Although CodeSmith with nHibernate templates is $99-$399 if you want nHibernate easily automated. It looks like OpenAccess has more transparency in the data layer and is probably easier to maintain. But, if you used something like Spring.Net you would not only have nHibernate automating the data but the service layer automated as well. Although take that with a grain of salt because nHibernate and Spring.Net are another batch of configuration files that need to be maintained. I bet OpenAccess is GUI friendly. Either one works, but there is alot more info out there on nHibernate.