I'm working on a new project right now and am thinking of using an ORM beyond that of Linq to SQL. I've currently got Linq to SQL wired up into a repository, but I'm not loving the way my Repo has to match my DB structure. (Example: I have a join between Users and OpenID's, and I need a 2 classes ( one for each table) and a class for the View that joins them).
I've heard some good things about Telerik's OpenAccess ORM and I do have a license for it (though outdated - Latest Version: 2009.1 405 (Apr 5, 2009))
My questions are...
Has anyone used it?
How is the learning curve?
Is it a good tool for my above scenario?
Is the version I have ok without having to update my license?
Our company is a $2.5B solar manufacturing company. When we started designing v2 of the application framework backend that all our applications would be based on, we took a look at the Telerik ORM. I spent a couple weeks looking at it. Our conclusion was that it was too complex, and a little flaky, for our needs. We went with L2S and have not regretted it. L2S has provided all the capabilities we need and is simple and straight forward. IMO, it's too bad Microsoft is spending so many resources on Entity Framework, because they have a winner in L2S.
Related
I have read some articles about automatic code generation of ADO.Net data access layers in .Net applications. There are some tools available like CodeSmith or LLBLGen Pro. Does anyone has experience with these tools? Is it better to use these tools rather than using LINQ? Thanks.
Better is subjective - however, I understand what you're really trying to ask. Essentially, my answer to the question of which tool is right (best) for the job is: it depends on the job. Linq -> SQL is older tech of which M$ has no plans of updating or improving. I would stay away from it... if you want similar functionality Entity Framework or another ORM is best.
NoSQL is huge right now and offers a big boost in productivity due to no database development or mapping or ORM layer to muck with. Just create your entities and store them! My recommendations on those are:
RavenDB
CouchBase
MongoDB
Riak
Redis
Cassandra
There are also graph databases useful for 'networks' of 'things' that are related in some fashion or another.... the two that I've used are below:
Neo4j (popular, java based, has .net client)
Sones (.net based - newer kid on the block)
As for SQL databases - well, some companies don't want to endure a paradigm shift or have requirements that stipulate only x database will be used in the company, etc... In those cases you have to work with whatever you have to work with. ORMs can aid in this arena... Some popular ORMs are listed below:
Entity Framework (M$)
NHibernate (very popular)
Subsonic (older but still used)
Dapper
Massive
PetaPOCO
And as for regular ado.net and to address your main question - there are not a lot of frameworks that generate the data layer for plain ado.net, etc... but I did find these and it turns out to be very useful in my projects:
http://www.elencysolutions.co.uk/ (not open source)
http://spgen.codeplex.com/ (open source & customizable)
http://www.nettiers.com/ (open source but sorta old-erish)
I am starting big asp.net project but I could not decided LLbl or linq to sql. Can you help me? What is advantage or disadvantage of linq to sql and LLBL? Which one should I use?
Thank you for answers. I wanna ask one question. I will use it for big project. How is linq to sql and LLBL performance? Which one is faster?
If your choices are L2S or EF and LLBL - Go with LLBL every day, all day, and sometimes at night. No joke.
LLBL has one of the most expressive Linq providers and incredible extensibility. The code is rock solid, unlike, cough... well you might know what I mean.
but let me tell you how i really feel about it.... lol..
The problem with Linq2SQL is that Microsoft is no longer developing Linq2SQL...
Is LINQ to SQL Truly Dead? by Jonathan Allen for InfoQ.com
Matt Warren describes [LINQ to SQL] as
something that "was never even
supposed to exist." Essentially, it
was just supposed to be stand-in to
help them develop LINQ until the real
ORM was ready.
...
The scale of Entity Framework caused
it to miss the .NET 3.5/Visual Studio
2008 deadline. It was completed in
time for the unfortunately named ".NET
3.5 Service Pack 1", which was more like a major release than a service
pack.
...
Developers do not like [ADO.NET Entity
Framework] because of the complexity.
...
as of .NET 4.0, LINQ to Entities will
be the recommended data access
solution for LINQ to relational
scenarios.
If you are thinking about LLBL as an alternative... might not be such a bad idea but I personally prefer Linq2SQL because it gives you a lot more freedom to create what ever adhoc queries you need. But if you need more structure then LLBL may be a better alternative... But then you have the Microsoft not developing Linq2SQL in the future to contend with.
Have you looked at Linq2Entities as an alternative or even NHibernate... If you need more on this, just let me know or look up linq 2 sql vs linq 2 entities...
Hope that helps.
Anthony
Deciding which one to use depends. You have not provided nearly enough information for us to help you decide. Both products have drawbacks that may or may not affect you. There are other .NET ORMs that may be a better fit, but you haven't made it clear why you rejected those.
You can read a lot more about .NET ORMs here:
NHibernate, Entity Framework, active records or linq2sql
Please provide more context around your question.
LINQ to SQL is not dead.
Microsoft does not deprecate it in .NET 4.0.
We are working on our implementation of LINQ to Oracle, MySQL, PostgreSQL, SQLite, and this implementation is actively developed.
Which orm you would recommend for a beginner moving from ado.net?... Thus far used ado.net stored procedures with asp.net and now like to move with an orm.. Any suggestion..
NHibernate is nice, but it does require a bit more configuration for the ORM (even though fluent NHhibernate is quite nice).
I have heard that beginners in .NET ORM's have had quite good success with Subsonic: http://www.subsonicproject.com/.
NHibernate. The new development branch - much better support for LINQ than the current released versions.
At the risk of sounding odd - why not http://msdn.microsoft.com/en-us/library/bb425822.aspx??
Yes, I know - Microsoft has officially said there wouldn't be much more development on it - even though it was bugfixed and enhanced in .NET 4. It's still in .NET 4 - so it'll be around for at least 3-5 years. It's easy to use - much easier than NHibernate - with a visual designer and code generation.
It's simple and easy to understand, and it can give you a great intro to using an ORM.
Once you've learned, internalized, and understood the principles, you can always move on to a more enterprise-ready solution, like NHibernate, or Entity Framework v4.
See Scott Guthrie's excellent blog post series on Using Linq-to-SQL for a great intro, or check out the Nerddinner tutorial which showcases ASP.NET MVC and Linq-to-SQL.
NHibernate is currently one of the most popular ORM's, but Microsoft has been busy working on Entity framework. In time this may become the most popular and the best simply because it comes with .Net Framework.
I'd second the LINQ2SQL option if you're using SQL Server.
LINQ2SQL:
is easy to learn, with lots of guidance available online;
has good tooling for design and debugging in Visual Studio; and
provides adequate performance for all but the most extreme of situations (StackOverflow uses it for data access, for example).
There have been rumours of its demise for a while, but Microsoft's market research seems to show more developer support than for Entity Framework which, whilst arguably more powerful, is also more complex. LINQ skills are transferable to other ORMs too, with options for LINQ2Entities (for Entity Framework) and, I believe, support from SubSonic also.
Entity Framework
Definitely try that out. Solid support from Microsoft themselves, support for Many-to-Many relationships, eSQL lets you at the lower layers, etc.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I have around 4 years experience of ASP.NET & SQL Server (only web forms). I have a little knowledge of Ruby on Rails and have developed one very small 2-3 pages application in ASP.NET MVC in my job. Now I and one of my friend ( same experience like me) are willing to gain more experience of ASP.NET MVC. For that purpose we have thought of developing an open source application in ASP.NET MVC. It can be a a blog system or forum or anything else so that community can also take benefit of it. But we are not able to decide the back-end database for the application between MySQL and SQL Server. What will you suggest in terms of following -
Which will be more supported or required by community?
If we use MySQL, will it be a tough road ahead?
Is there any chance of supporting both by using ORM (I have no experience of working with any ORM)
Any other suggestion ?
Thanks in advance.
If you can't decide which to use as a backend, then one suggestion I have it define an interface for the data layer, use the IRepository pattern against this interface, and simply pick one and write an implementation of the data layer for that choice. In a (successful) open source project, it's unlikely that everyone who wants to use it will have the same ideas about what database will work for them. In that case, designing it so that it can use any database, given a suitable implementation of the interface is a wise move. Using something like nHibernate, which already supports many different databases may be the route you want to go if you don't mind having dependencies on other libraries.
Which will be more supported or required by community?
For most business users, and most dedicated ASP hosting providers, it will be Microsoft SQL Server IMHO. With a surprising spread across version numbers. I see quite many SQL Server 2008, a lot of 2005, and quite surprisingly many 2000's too.
For small "we're cheap, is it gratis?" businesses and individuals, I do see some MySQL on Windows too. I guess in my little circle of companies that I've worked with, it is 2/3 MSSQL and 1/3 MySQL of the two databases you mention.
If we use MySQL, will it be a tough road ahead?
In terms of more difficult development? Yes and no; LINQ to SQL is more or less only available for MSSQL, and many find it to be a simple and natural technology to work with. So "yes" if your plan was to use LINQ to SQL as your ORM of choice. Other good ORM's like nHibernate work equally well with both databases, as elder_george says.
Is there any chance of supporting both by using ORM (I have no experience of working with any ORM)
Sure, f.x. with nHibernate, and a bit of extra XML for nHibernate configuration, and some more extensive install docs, SQL scripts et cetera for the users.
Any other suggestion ?
Since this is your first application, play around with the design first using mocksups & prototyping, UML or something else of your choice. See if you can get some experienced MVC developers to critique your design, but don't take their critique as gospel, there is more than one way of doing things right.
Definitely consider tvanfosson's suggestion to use an IRepository to provide flexibility on the storage layer.
Consider using unit testing and dependency injection from the start too; both are IMHO very important and helpful in the longer run. On the downside, that would be a lot of new technology if you don't have prior experience with these.
MS SQL is easier to use with .NET. .NET includes LINQ to SQL ORM out-of-box, so nothing has to be installed.
MS SQL has a free Express edition but it's up to you to decide whether its capabilities (4Gb for DB, 1 CPU only and so on) will be enough for your application (IMHO they will be =))
There'are ORMs that allows to switch between DBMS's: NHibernate, SubSonic, DbLinq. NHibernate is the strongest beast out there, and it has an active record implementation built if you are looking for familiar concepts from RoR.
tvanfosson and elder_george had given good comments.
ASP.NET MVC aside, it's more of MySQL vs MSSQL. I've developed web projects using both and find them relatively on-par from a development point of view. ORM I've used is NHibernate.
From deployment/production perspective, you will be bounded by MSSQL Express edition's limitation, assuming you are not going to pay for it. You might want to spend some thoughts in this aspect.
Use ORM -> NHibernate
https://www.hibernate.org/361.html
I was in a similar situation a couple of months ago. Now my newest project on ASP.Net MVC is almost complete. Here's the set I chose
--ASP.Net MVC + MySQL. No ORM.--
I decided to go with MySQL instead of MS SQL because MySQL is free, and MS SQL is very expensive. If you're making an open source application, you gotta think about that seriously. This is going to be a major problem if you are targeting widespread adoption of your application.
At first I tried to use MySQL through an ORM -- Enterprise Framework (EF). It was the worst decision ever. Enterprise Framework totally killed the performance. It was the pits of the pits. I believe nHibernate is better, but I don't know how much better.
With my own SQL code things are fast enough.
The first iteration of my site will be in public beta this week and then there will be several iterations.
It went rather well so I car recommend the set I chose with ease.
We are getting ready to begin redevelopment of a large aging internal enterprise application. We have decided to use ASP.NET MVC, but under consideration is which Object Relational Mapping (ORM) to choose. There are of course a multitude of open source and paid ORM implementations available. However, NHibernate seems to hold the largest mindshare, while the Entity Framework is the new hotness from Microsoft.
While we are doing research and toying around with both we wanted to put it to the community as to which ORM (NHibernate, Entity Framework, or otherwise) they prefer and why.
Somewhat similar Stackoverflow Questions
What are you favorite .NET ORMs? (good list, but w/o justifications)
ASP.NET MVC + ORM (focuses primarily on Castle Project AR)
What object mapper solution would you recommend for .NET? [closed question]
Additional .NET ORM Reading
ORM in .NET 3.5
Why use the Entity Framework?
Why use the Entity Framework? Yeah, why exactly?
Best .NET ORM Tool
You should have a look at Sharp Architecture an ASP.NET MVC application framework which uses NHibernate.
I've used a few O/RMs in the past couple of years and there's no way would chose anything other than NHibernate.
It's the most mature.
It's got a huge set of features.
It's got a good community behind it.
It's got some fantastic ancillary projects such as Fluent NHibernate.
I don't know what more information people will be able to give you over and above in the questions that you have linked to.
Crazy talk answer: none.
This is not to say ORMs are not awesome pieces of technology when used right. But in 2011, they are quickly becoming the universal hammer where not all problems are nails. And there is so much going on in the modern ORMs that, especially for people not well versed in them, they can confuse things more than help things. Or, sometimes things are simple enough that straight SQL is a better alternative. No matter how good the ORM is, the abstraction will leak at some point.
The other side of things to look at is the whole NoSQL movement. The technology is still a bit new, but for new work it is a data access strategy one must consider as it takes so much cruft out of building your application.
Short answer: use both (i do really use both)...
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