Has anyone used this ORM?
Telerik OpenAccess
Critiques/Praise? I work in an office that is heavily invested in other telerik venues and I would like to know more about their newest product and whether or not it should be avoided.
I'm testing it, the free Express version.
Pros
Performance (caching, lazy load etc. out of the box)
Easy integration
Great VS.NET integration, wizards
Cool community
Cons
Missing real distributed architecture support and patterns
Wizards hide configuration files and sometimes you must fix thing with hand
SQL CE support still missing
Chris is right, but Entity Framework works like beta, and OA has LINQ support too.
Personally, I think .net's Linq and it's entity framework are the best since sliced bread. I also use telerik a lot and look into everything that they make but ORM doesn't compare to M$ .NET Linq.
Chris
Related
I know this has been asked several times and I have read all the posts as well but they all are very old. And considering there have been advancements in versions and releases, I am hoping there might be fresh views.
We are building a new application on ASP.NET MVC and need to finalize on an ORM tool. We have never used ORM before and have pretty much boiled down to two - nHibernate & Entity Framework.
I really need some advice from someone who has used both these tools and can recommend based on experience. There are three points that I am focusing on to finalize -
Performance
Learning Curve
Overall Capability
Your advice will be highly appreciated.
Best Regards,
I would use Nhibernate. I would pickup Sharp Architecture as a great framework that wraps NHibernate, ASP.NET MVC and a bunch of other open-source tools into a coherent whole that will give you a solid architectural foundation.
Nhibernate is more mature than EF4. It is well supported by the community. As long as you are willing to get your hands dirty from time to time, you will like it. It's support for LINQ is currently a little weak but it is rapidly getting better. The learning curve is not bad, but things like session management can be a little confusing at first. One of the reasons I like Sharp Architecture is they have all the NHibernate stuff you will need in place and plenty of guidance on how to use it properly in an ASP.NET MVC project.
EF4 has the MS stamp of approval. It is pretty good now but still behind NHibernate. It is a perfectly good choice and you will find lots of docs from MS, MS support and eventually more developers that are familiar with the ins and outs. I should also mention that the Sharp Architecture folks are adding support for EF4 to their overall framework. They will still support NHibernate, but you will be able to use EF4 if you like.
I think it takes more time to learn NHibernate.
EF provides graphical designer, unfortunately NHibernate doesn't have a generic designer. BTW it's not a problem. If you design in domain-driven (DDD) manner, you will design your entities first and you don't care about database structure (as you used to), NHibernate will handle that for you.
EF 4 got closer to NHibernate. I wouldn't start working with EF 3.5, it lacks a lot of features.
If you think NHibernate is too complicated at first sight, you can start with frameworks built on top of NHibernate. ActiveRecords and Sharp Architect are good examples.
AFAIR EF 3.5 supported only SQL Server 2000. It couldn't handle the new data types from SQL Server 2005. I have no information on EF 4 but I suppose it support these improvements.
If you use NHibernate in real word applications, you have to build an infrastructure. E.g. I implemented the Unit of Work and Repository patterns to be able to write tests and create layers in my application. You have to expect the same using EF. Detaching and attaching entities in EF 3.5 was not an easy thing, I had to write tricky extension methods to mark fields dirty and so on. I hope they solved it in EF 4. There is no such problem with NHibernate.
You don't have to write HQL queries in NHibernate, you can use the LINQ provider. I think it's very important. :)
All in all NHibernate is a mature product with good community and commercial support. EF is young but strongly supported by Microsoft. Oh, and EF is a Microsoft-only thing while you can port your NHibernate knowledge to Java as well. It this counts for you.
I'm trying to look into this...
After building apps into both, NHibernate is definitely more powerful, but it's also quite clunky where EF is very clean. And after working with Rails/ActiveRecord, both are very feature rich in comparison, so either would definitely work!
I noticed that NHibernate keeps track of what it just ran, and if it just ran a statement, it doesn't exectute it again, so a properly designed app will run minimal database statements. I know that EF is not exactly slow either, but I'm not sure if it caches statements and results in the same way. For a large app, this could save some database resources!
So in short, NHibernate for functionality and configurability, and EF 4.0 for cleanliness and a quick easy learning curve. Also, one should expect EF in the next version or two should may catch up to or surpass NHibernate in functionality too, so it may make sense to have some familiarity with both.
just take a look at this
http://gregdoesit.com/2009/08/nhibernate-vs-entity-framework-a-performance-test/
I am trying to work out with ORM tool to move over to and have narrowed it down to two candidates.
nHibernate or LLBLGen Pro
Please can you guys give me pros and cons in using both these tools especially if you have experience in both. I am not really interested in any other tools but am wanting some heads up so I can decide which tool to spend time learning....
I already know that one is free and one isn't, I also know that nHibernate might take some learning....
Many thanks, Richard
I have used both. At first I was sold on nHibernate and refused to try anything else even though I knew about other options.
With LLBLGen Pro, I was skeptical, but soon saw the advantages as well. I have not totaly abandoned nHibernate. I will continue to keep int in my "box of tools". I have found LLBLGen useful in some cases especially when interacting with a database that already exists and you have no choice of re-designing it. It takes less than an hour (depending on size of database of course) to generate my LLBLGen Entity Objects from the database, as opposed to having to code all of it manually with nHibernate, AND do the mappings. nHibernate is missing a nice graphical interface to create the mappings. This fact becomes even more important when the database is massive with thousands of tables that you need to potentially access in your application.
Although LLBLGen is more of a Data Access Layer generator (And I am not normally a fan of DAL generators), it has a lot of features a "true ORM" tool would have. In my opinion it has the best of both worlds. Once you start working with it you start to realize that it is very flexible and extendable. One part I like a lot is that it is possible for me to create partial classes for the generated entity objects, where I can code in my business logic, as well as validation.
The code generation is templated so you have full control over the code it generates. With nHibernate I find myself writing some of the same kind of code over and over again. With LLBLGen I can generate it and get to focus on business logic and issues quicker.
For someone who is just starting to use ORM type tools, I really recommend to start with LLBLGen, because nHibernate can be overwhelming. And in the end you will have achieved the same result (More or less).
Edit #1: LLBLGen now also has 100% support for LINQ. (So if you like LINQ to SQL for that reason) further LLBLGen can support many databases, where LINQ to SQL is only for Microsoft SQL Database.
Edit #2:
According to Graviton you can use CodeSmith to do some of the code generating for you for nHibernate. That is really cool, but for a newcomer to ORM I would still recommend LLBLGen. To me that is adding more dependencies where LLBLGen has it all in one package. Also like I said before the learning curve is so much less steep and you will get the same benefits, which will also help you ease in to nHibernate if you ever decide to go there.
The major difference is that LLBLGen is a code generator, while NHibernate is a "true" ORM library.
LLBLGen advantages:
Easy to use model designer. Can import your existing database schema
Fully typed object model and query language
LLBLGen disadvantages:
You need the designer application to change your model
Not free
Can bloat your code because a lot of code is generated
NHibernate advantages:
No designer application needed. Only code
Widely used (based on the most popular Java ORM, Hibernate)
Very powerful for mapping any data model you can imagine
Open source
NHibernate disadvantages:
Hard to learn
Not as strongly typed as one would like (especially queries)
Of course, this is just my personal point of view...
I typed up a fairly long answer before realizing this was a somewhat old question. Oh well. It's still very relevant.
You have narrowed your list to the two best candidates for an ORM in the .NET world. I have limited experience with either, but I've read extensively about the pros and cons of both. They really serve somewhat different needs in different ways.
In the upcoming LLBLGen Pro 3.0, Frans Bouma has talked about adding features to generate NHibernate mappings. So, it's not even necessarily an either/or decision.
If you want to do "class first" design (as opposed to "database first" design), NHibernate is pretty much your best and only option right now (neither LLBLGen Pro nor Entity Framework support this mode, although it sounds like Entity Framework is improving it's support in the next version).
NHibernate and LLBLGen Pro both work hard to work well with legacy databases which you can not change and have to live with. That is their common strength. They both also work with Linq. They both also support some amount of graphical modeling, although LLBLGen Pro is far superior in this regard (ActiveWriter for NHibernate feels like the LinqToSql designer in Visual Studio, but it's not really as feature rich).
LLBLGen Pro has much stronger code generation abilities, but too much code generation can lead to compromised testability and maintainability (one small tweak can cause massive amounts of code to need retesting).
While NHibernate wants to help you work through fairly complex object/relational mapping scenarios like class inheritance, LLBLGen Pro is really just exposing your database as a data layer and business objects in a very quick way.
If you can purchase LLBLGen Pro and have some time, I would try both and see which one better meets your needs. Learning both ORMs is good for your resume in any case.
So, in the end, I would say it's situational. The cost of NHibernate and its lack of serious flaws make a pretty compelling case in the majority of situations.
The new version of LLBLGen Pro (3.0) allows you to generate code for NHibernate, so don't have to choose :). It also allows you to split up your entities into different domains.
I still prefer the LLBLGen pro runtime though, the LINQ interpreter is more complete and it has better change tracking of fields.
Unfortunately there's not many new features in the new LLBLGen Pro 3.0 runtime, as the creator first wanted to focus more on tooling than improving the existing framework.
I've used nHibernate, LLBLGen Pro, a custom data layer from my consulting company, the Enterprise Library, and LINQ. LLBLGen is by far my favorite and it allows writing one business layer that can talk to different types of databases using the same code providing database independence! Another incredible feature is it allows multiple connections to different databases. This is very useful when at a large company and one system is written in Sql Server and the other you have to interface with is in Oracle.
LLBLGen Pro is an amazing product backed up by Frans who is very active and works hard to fix issues. LLBLGen is like PhotoShop, it is an incredible tool and that can do amazing effects in the hands of someone who knows how to use. And like any tool that saves lots of time, it takes a week or two to learn how to use it, but will save months later on your project.
Not only did it speed up the DAL generation side of my app, it is also easy to create queries in the Business layer and send to the presentation layer. It made it easy to create an enterprise class application.
If one really wants to use nHibernate, start with LLBLGen Pro and generate the nHibernate code. If later on your department decides to switch from nHibernate to LINQ, you are covered. Want to switch from Sql Server to Oracle? This is possible and relatively easy with LLBLGen whereas with manually coded nHibernate code, you have to rewrite everything which is almost impossible to cost justify.
Frans was also available and answered some of my questions.
Don't forget one of the greatest plus point of Hibernate: HQL. With HQL, your SQL skill is not wasted. And Hibernate provides very nice, seamless support for native query as well.
If you have some weird, out-of-standard database, it's almost certain that you need your SQL skill at some point, and good luck with LLBL!
For me it boils down to database centric (LLBLGen Pro) vs. domain model centric (NHibernate).
Since I'm a DDD/OO guy, the choice has always been very easy for me, but I do see why LLBLGen Pro is popular.
We use LLBLGen at work, and it's reviled -- namely because we have multiple similar schemas, but you need to have a different DLL/Class library for each schema, meaning that it becomes annoying to write code that can target any schema.
Of course, that's an unusual environment, so it may not apply to you.
I need to collect some information about existing ORM solutions.
Please feel free to write about any programming language.
Can you tell about the best ORM framework you ever use and why is it better then others?
I used NHibernate and Entity Framework.
Current stable version of entity framework is very immature. It is too difficult, or impossible to perform common tasks. Testing your code is also difficult since you cannot really separate your entities from your data access classes. But it perfectly integrates with visual studio ide. Setting up is easy and updating all the models from database takes just a few seconds. Upcoming version of EF (4.0) will solve some of this problems.
NHibernate is quite powerful. It supports plain old clr objects, so you can work with simple entities. Configurations provide great control in great detail. Framework capabilities are satisfying and it has a large and active community and good documentation. Setting up and updating entities is a little difficult since you must use generators that looks up your database and generates entities and xml files. It may be tricky to find a generator or a template that exactly fits your needs. But once you set all things up, you will love it.
I found LINQ to SQL to be a pretty straight forward solution. The first time I used it, I'd say I had a basic ORM working within a few hours, and was creating LINQ queries with it.
Microsoft has an additional ORM (Entity Framework), which I've heard is more complex but may be useful for highly complex distributed applications with multiple data sources etc.
Overall I found LINQ to be an easy and fast to use ORM.
I have been looking at Telerik Open Access for last few months, in genernal this ORM has been a pain to work with, it was advertised as having extensive linq support but in reality many of the linq features you would normally expect dont work server side and are performed on the client. I also had problems using multiple conditions in a where clause, see my last question. Here are a few things that i found
No support for views
Unable to map more than one entity to the same table
Inheritance and Interface support requires you to make changes to you database schema
No visual designer like LINQ to SQL and Entity Framework
If you want to perform an insert any related entities must be fetched first
Rohan
LINQ2SQL was nice, EF makes sense, but is very complex and SQL Server oriented. NHibernate is special and Telerik OpenAccess (fully .NET / Visual Studio) got a broad set of functionality and professional support.
Since I know the product I can comment on Rohan's concerns:
Existing Views can be used and full Views support is coming up
Mapping more than one entity to the same table "works" for class hierarchies, limitation with reverse mapping exists
Inheritance and Interfacer support "do not require" changes to the the database schema, again limitation with reverse mapping exists though
Visual Designer will come, Forward and Reverse Mapping Wizards allow you already to do anything in an easy way
There is a workaround for the insert issue mentioned and it will be fixed generally
Check out the Telerik site to find happy customers and feel free to use the telerik forums and support resources for any question.
-Peter
Im new to OpenAccess ORM and we are using two products. Reporting and OpenAccess.
I think there are some features that people missed.
OpenAccess uses graphical designers while nHibernate still uses handwritten xml files
OpenAccess is not limited to SQl Server as EF4 and similiar frameworks
using it is easier and the forums are pretty helpful.
With ORM there are multiple possibilities, all depends what you want.
As a real ORM mapper I strongly recomment NHibernate and Fluent NH mappings. You need a lot of research to put together a nice architecture, but then nothing stands in your way. With minimal compromises you get real flexibility.
EF6x (core is not prod.-ready IMHO) is called an ORM, but what it generates is more closer to a DAL. There are some thing's you can't do effectively with EF6. Still, this is my favorite tool for a read-model, while I do combine it with NHibernate (where NH I use for a DDD/write model).
Now to performance - its always pro and cons. If you deep deeper into ORM architecture (see my article: avoid ORM bad habits) then you will find intuitively the ways to make it faster. Here's my another article on how to make EF6x 5x faster (at least for read situations): EF6.x 5x faster
Forgive me if this is a repeat question. I've searched StackOverflow and did not find the answer to my question, so here goes.
We currently have a web application running ASP.NET 2.0 with AJAX Extensions 1.0 and SQL Server 2005 running, is deployed on IIS 6 and developing in VS2005. All works great, but I'm trying to find compelling reasons to migrate. The clients we serve to do not permit plugins in general in browsers, so Silverlight is not a reason for us to migrate. Also, we don't have any plans to migrate to SQL Server 2008 any time soon and ASP.NET MVC is not in the works either.
Here's my reasons to migrate. I would like people to comment on them or add to the list:
I want to work with the newer .NET stuff (and I think other developers would too. Also appealing to prospective employees)
Want to keep the technology up to date.
Extension methods
PageMethods in WebControls
WCF
LINQ maybe (we currently use AutoSproc for our DAL)
ASP.NET AJAX built-in to ASP.NET 3.5 (not really a big deal though)
VS.NET 2008 JavaScript Intellisense
My favorite parts are:
Lambda expressions
Functions available in the
System.Data.Linq namespace:
Where(...), OrderBy(...),
ForEach(...)
Extension methods (add a "ToDelimitedString(...)" to all IEnumerable!)
Visual Studio 2008 is nicer with
HTML/web syntax and debugging,
including the aforementioned
Javascript intellisense and
debugging.
Each of these allow you to write code in a more productive manner.
It largely eliminates the boilerplate "foreach", "if x != null", and other boring constructs.
The javascript intellisense is a huge improvement over anything that's come before. But at the same time it still fails in some very spectacular ways. All in all a good step but not something I've been able to use as much as I'd like.
The extension methods and linq (linq to objects and lambdas, not just linq to sql) are very cool, but since you have an orm already set up you won't use them as much as you'd like either.
WCF is okay, but you're probably not going to re-write your existing services for it.
I think the biggest reason up there is keeping your employees happy and attracting good new ones.
You have absolutely no reason to upgrade, from a business prospective.
You have absolutely every reason to upgrade, from a developer prospective.
Just keep in mind that SQL 2008 is not backwards compatible with SQL 2005, meaning, if you develop something in SQL 2008, chances are, your 2005 platform will barf at it. I just recently experienced this with SSIS packages.
LINQ is a reason to upgrade, even if you don't swap out your DAL, or don't do it for a while. In the product I've been working on lately, our development schedule is such that there's no room to change our DAL to a LINQ-based one for a while yet, but even so I find good reasons to use LINQ-to-Objects and/or LINQ-to-XML in probably 60% of the classes I touch, and I love it.
Everything still runs on .NET 2.0, it's just library and language enhancements and an improved IDE experience, which are made to increase productivity. Increased productivity = justification.
I use LINQ all the time now, every single day. It's not just for your DAL. It's about querying anything, with the same API over top. More generally, lamba expressions provide you with the ability to do some things that are very complicated and take a lot more code without them. Anonymous types are very useful as well.
All the points mentioned are valid.
But as a developer, when facing this kind of question, I always ask myself from the other side.
What is Compelling Reasons NOT to Migrate from ASP.NET 2.0 to ASP.NET 3.5? I find it easier to get myself motivated to upgrade.
The free Microsoft ASP.net Chart control and the new version of Ajax tool kit both require 3.5. If i'm not mistaken.
We are changing from vs2003 to vs2005 and use vb as our primary language, I am looking for some of the changes to VB that will be helpful in our ASP.NET development. Can someone point me to a list (maybe from microsoft?) or provide some of their favaorite differences between the two versions?
WHOA! Not so fast there, buddy! What's the rush? Relax, guy. Give it a few more years.
Any .NET developer not working version 3.5 of the framework is just wasting time. Every single bit of it... Linq, WPF, lambdas, WCF, GENERICS, I could go on... Every SINGLE bit of it is gold. I'd rather play on a highway than target 1.1. Its like night and day.
Do yourself and your team a favor... Skip 2k5 and hit 2k8.
What's new in VB 2005 (from MS)
The same topic covered in Code Magazine
From a language perspective, the addition of Generics and Nullable types (second link) (built on Generics) was a pretty compelling story for my work. The My namespace provides VB developers with quite a few shortcuts into "somewhat" more complicated features of the system.
From an ASP.NET perspective, even though they weren't VB-specific, the addition of the Master Page framework and MembershipProvider architecture were also very valuable.
Here's a fairly comprehensive list from Microsoft of all the Visual Studio 2005, language and major .NET framework changes.
For what it's worth, you might consider just jumping over 2005 and right into 2008, with .NET 3.5.
Rick Strahl takes stock of the major changes and provides a personal perspective on some of the highs and lows.
.NET 1.1 to .NET 2.0 Migration
Article 1
Article 2
Better IDE for one.
I found the biggest improvements from .Net 1.1 to 2.0 were generics and yield return for easy implementation of ienumerables.
I personally find some of the IDE changes to be of the best benefit.
The fact that the designer DOESN'T re-format your code as it feels like it
The fact that standard layout is DEFAULT rather than grid layout
Improvements in intellesence
In addition to the IDE changes, if I had to pick 1 .NET 2.0 thing that is a huge helper I would say generics.