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.
Related
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.
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 is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 22 days ago.
Improve this question
I want to learn ORM and I wonder which is beneficial for start up; Linq to SQL or Nhibernate. considering time,adaptation... etc
One important question to ask yourself is if you can accept a dependency on SQL Server. Will the database backend change to Oracle, for example? LINQ to SQL is strongly coupled to SQL Server, whereas NHibernate isn't. I'm not saying that this is necessarily a bad limitation, but it's important to consider.
NHibernate has really come a long way in the past few years. I really like Fluent NHibernate, for example, but that's not to say that LINQ to SQL is limiting. I love the integration with Visual Studio and it has proved itself more than capable of handling consistent load (Stack Overflow uses LINQ to SQL, for example).
Contrary to popular belief, LINQ to SQL is not dead.
Edit: Another important question to ask yourself is if you want to change the domain model. LINQ to SQL maps objects directly to tables. NHibernate, on the other hand, allows for a layer of indirection. This is also true of Entity Framework, by the way.
I'd go with NHibernate, because there's a nice open source community out there that supports it, answers questions on it, and so on. As your product gets bigger and more complicated, you'll appreciate the power and flexibility of NH. Finally, Linq-to-sql isn't in MS's long term plans, since they want you to use the Entity Framework, so you might end up with a dead-end technology there.
I would put in my vote for Linq-to-SQL - why?
it has a visual designer which allows you to more easily and quickly get results and see something
NHibernate is very powerful - but that also makes it harder to learn; you have to really really love angle bracket soup (i.e. lots of XML mapping files) to get up to speed with NHibernate
If you don't have experience with ORMs Linq to SQL is slightly easier to learn than NHibernate. It also has better integration with Visual Studio.
I love Linq to SQL, it's very easy to use. Implement the repository pattern and use LINQ to SQL as your first implementation behind your repository interface. You'll find it's so easy to get a repository up quickly using the tool. You can always implement a second repository using NHibernate without breaking your app then compare your experience with the two tools.
NHibernate is "more powerful"... I guess that means you can use it against any database, and that's about it. There's a lot more to learn and if you do go that route, make sure you make full use of Fluent NHibernate to avoid all the mapping rubbish. It's much cleaner that having a bunch of XML mappings to maintain.
I find NHibernate frustrating becuase I like querying the database with LINQ and projecting (mapping) to a model . I know there is a LINQ to NHibernate floating around, but I can't say I know anyone who uses it.
Generally, I would say to use NHibernate if you are happy to get everything by ID and traverse the object model from there. As soon as you want to execute more complex queries you had best be prepared for some frustration.
Linq to SQL is supposed to be replaced by the Entity Framework; I think NHibernate would be a good choice since there are lots of references and it seems be widely used as well.
In addition to Darin answer, Consider this post i read earlier.
Linq to SQL is easier and faster to implement and integrate quickly, but Nhibernate can give you more flexibility if you need more control. Recently, i had to decide if i was to use Linq to SQL on my new app project - i just didn't like the lack of flexibility.
NHibernate vs LINQ to SQL
http://www.acceptedeclectic.com/2007/12/linq-to-sql-vs-nhibernate-part-1-what.html
Let me know if it helps.
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