I have to build a website for a news channel..
Please help me decide which technology to use for data operations?
1) Linq to Entities
2) Linq to SQL
3) Fluent NHibernate
4) ADO.Net
Website will be based on ASP.Net MVC and C#.
Main Issues:
1) Should be easy to maintain and scale.
2) Good Performance
Please express your view with an example if possible..
Thanks
Chitresh
Pro and cons:
LINQ To Entities
Allows you to add another layer of abstraction (entity) instead of mapping directly to tables (like in LINQ to SQL). Support multiple data providers (not just SQL Server). Require a bit more learning time than LINQ to SQL. Provide unit of work concept. Medium to High learning curve.
LINQ to SQL
Allows you to easily map your tables, stored procs, etc. Provide unit of work concept. Only work on SQL Server backend. Easy to implement, but require dbml rebuild if db schema changes (1 way synchronization from db to object), so a bit harder to maintain. Low - Medium learning curve. Performance, ... I think Stack Overflow is using LINQ to SQL. How do you think it performs? Have unit of work concept.
Fluent NHibernate
Can't comment ... know nothing about it. If it is anything like NHibernate, should be quite flexible. Probably high learning curve. Someone correct me on this...
ADO.NET (Not talking about Named DataSet here...)
Should be the fastest (no abstraction). Flexible, bend it anyway you want. Low learning curve. Very basic, do everything yourself approach. Most of the time I go this route for simple project. Can lower productivity. You can augment it with code generation to gain some productivity.
Your other options... Subsonic perhaps.
NHibernate(Fluent NHibernate)
Fluent NHibernate is a component to help you map your Entities so that NHibernate knows where it's gonna put your data from the database. If you never used NHibernate it can be a little difficult to know how to map and handle a NHibernateSession but there are lots of information here on stackoverflow and other places like S#arp for an exemple of session handling and Summer of NHibernate to get some lessons in mapping.
I would go with Linq to Entities or NHibernate (actually, I would go with NHibernate, but that is one I'm the most familiar with) -- AND ADO.Net (but just a little bit).
Start by doing everything you can with NHibernate/Entities. Once it is up and going you will find it remarkably productive. But there are situations where you will need a bit more performance (do you have a good profiling tool?). For those cases, code them in straight Ado.Net (that should make up less than 10% of your database calls). With NHibernate, you can use the NHibernate session to get your connection object for you as well.
Related
I am planning to work on a new ASP.NET WebForms site in .NET 4.0. I used to use Linq to SQL and now I am thinking about EF4. My database is SQL Server only ever, simple business objects and most probably one to one relationships between Business objects and database tables.
It seems EF4 in its simplistic form works very much like Linq to SQL as an ORM. Drag the tables into the designer and with LINQ to do the database stuff.
Instead of learning and using two ORM's, it seems EF4 can do all of it. From the simple to the complex projects. From SQL Server only to hybrid database engines.
Will I miss anything if I go with EF4 only all the way for all kinds of projects and leave LINQ to SQL behind? I know EF4 is more complex (steeper learning curve) for simple projects but I don't find this a good reason to split my energy & time between two ORM's when one (EF4) can do it all.
I think the main negative point about EF4 apart from the steeper learning curve is its performance. Linq to Sql is faster and if that is important for your project than you might have to consider choosing Linq to Sql or straight ADO.NET instead.
However in most cases when performance is not a crucial issue for either simple or more complex projects I share your idea of not splitting the efforts and concentrating only on EF4.
What are the advantages of EF4 and under what circumstances is it preferred over LINQ to SQL?
LINQ to SQL will have no more future development. So EF is the way to go in the future.
Entity Framework vs LINQ to SQL (this should explain what you want to know)
Well, two of the major differences are:
1) EF can target multiple database engines, including Oracle and MySQL. Not just MS SQL Server.
2) You can do so-called "code first" schema development. Basically you create your object model, and along with some hints, EF will generate the schema for you.
Seems to me that Linq to Sql is great for rapid prototyping and simple CRUD scenarios. Anything more advanced or enterprisey would use EF4. (Or at least that's what MS would like us to believe :) I've had good luck with Linq to SQL in production, for what it's worth.
EF4 basically adds a whole bunch of OO-ness to the mapping that isn't present in LINQ-to-SQL, such as rich object inheritance models. My own take on it is that none of that is necessary for good design, and I have yet to come across a single scenario in my own work that warrants the added complexity EF4 brings to the table.
Having said that, Microsoft has deprecated LINQ-to-SQL and will not continue developing it, so it will eventually fall behind EF4 in capability and efficiency (if it hasn't already). So the pragmatic choice is simple: go EF4.
After trying both and spending over one weeks porting a project from linq to sql, I can say that I really prefer Linq to SQL. The main reason for this is that EF is more restrictive on what functions you can use in LINQ queries. In EF I had to cast my linq expressions to a list to be able to manipulate them any further. Sorry for not being able to remember any example, it's been a few months since I did this...
One of the really big plus sides for EF, is the ease of use in connection with WCF Data Services. Very handy if you are developing a web site that should have an RESTful API.
Also, even though Linq to SQL is quite mature, it is indeed a dying technology. It won't get any significant updates, that makes it harder to commit to Linq To SQL for a new project.
We're working on an ASP.NET web application with C# code behind. The database is MySQL 5.1 using InnoDB. The data access layer uses ADO.NET to call stored procedures and then builds various data structures out of the result sets (no object mapping). This works fine, but it is a little verbose.
Not surprisingly, we made some mistakes when designing the first version of our data model, but the experience has made us smarter and we decided to refactor the data model. We don't have to change our data access layer, but we are considering our options for that as well.
It's been difficult for us to ignore the popularity of ORM tools these days; we feel like we are way behind or something for not being familiar with them. Not only that, but we have already designed an object model that nicely describes our data model. The main ORM tools we would consider are NHibernate, ADO.NET Entity Framework, and LINQ to SQL. We would prefer LINQ to SQL because we have read (on S.O.) that it is more light weight than full ORM tools.
We think one drawback to using an ORM tool is the learning curve, but we can already see how using LINQ could reduce the amount of code we will have to write, which could save us time in the long run. However, we are using MySQL, not SQL Server.
So my question is, would DBLinq work well enough for a production system? Or, is LINQ to SQL a compeling enough reason for us to make the move to SQL Server 2008? Incedentally, I'd prefer to use SQL Server over MySQL, but cost is the obvious drawback. After 3 years on BizSpark, we'd be on the hook for $6K. Or, should we consider other ORM tools instead? Or, should we just ignore the hype and not use an ORM tool, but maybe take advantage of LINQ to DataSet?
I searched S.O. for info on DBLinq, but only found 17 questions with the DBLinq tag, so it doesn't appear to be popular.
EDIT
Looks at though dotConnect for MySQL has support for LINQ, so that's another option.
Can anyone speak to how well that driver works for writing LINQ queries?
Check bl-toolkit. It's free, very fast and has great LINQ support. Newest addition are T4 templates for generating your data model from database.
I am trying my best to understand what is the difference between "ADO.NET - Entity Data Model" and "LINQ To SQL", but I cannot figure it out.
Can someone please explain the differences between the two and the advantages and disadvantages?
Thanks
Frank
Linq to SQL was actually a proof of concept for Linq. See The Origin of LINQ to SQL. Microsoft is putting its weight behind Entity Framework, although I believe it's not quite ready for prime time.
Anyway, this StackOverflow post provides some additional detail about the differences.
Linq to SQL is said to be dead (I don't think so though - it was way to well received by the development community). Entity Framework is its successor, if you want. It can access more data sources (more database types, and also different kinds of sources such as reporting services, business intelligence etc.). It's much more complex than Linq to SQL, and has a steeper learning curve, for example EF allows one class-multiple tables mapping. Other things are not possible with EF, such as specifying deferred loading - that's Linq to SQL only.
Our team is now beginning to look at jumping from 2.0 to 3.5 and have been reviewing all the new stuff....
So, with the whole Linq to SQL not being heavily improved in the future should we ignore it completely?
It seems that it may fit of our needs very well BUT I imagine so could entity framework even if it may add more complexity.
So avoid Linq To SQL like to plague and go with entity framework instead or jump on in, Linq To SQL will be just fine in 4.0 and future releases even without improvements?
Everything I've read seems to suggest that Linq2SQL will still be around for a while. I would, if I were you, just pick the one that best suits the problem you're trying to solve. I might be a little biased toward using the Entity Framework because it's more abstract and might be a good capability for you and your team to have, and because Visual Studio 2008 has a designer for it.
I just don't think it's that big a deal for a few years. Just pick the one you like the best for now.
Update: lest there be any confusion - using the EF doesn't mean giving up Linq. Linq can already be used with the EF.
Very similiar to my question # Switching to LINQ
Might offer further insight/opinions.
Personally, I am going to start focusing on EF since everything I see coming from MS is that LINQ is just the beginning and a big part of the foundation of EF.
I would pick LINQ only because it is simpler, and when you finish your application, and are looking at optimizing, and refactoring, then you can try Entities, and see if you have any performance improvements, or if it makes the code better.
I tend to start with the simpler, faster-to-develop, method, to get the functionality finished, then I refactor, then optimize.
I'd have picked EF in any case. I never liked the idea that LINQ to SQL mapped directly to the database structure. I greatly preferred the idea of EF, where I can decide what entities I want to present to users, and then map them to the database tables as appropriate.
LINQ to SQL and Entity framework are not comets passing by. They are real coding revolutions !
We can now query databases in 1 hour where it took us 1 day before !
Do not hesitate to jump. If .Net 4.0 does not suport LINQ to SQL or Entity framework, just stick to 3.5 !
:o)
All the best, Sylvain.
If LINQ to SQL fits your needs, then go with it. Its really a very powerful RAD tool.
EF will give you more flexibility, but also perhaps unnecessary complexity.
Its a shame LINQ to SQL isn't moving forward anymore, but I'd stick to it until EF really matures and allows equal RAD development, unless of course, you need EF features now.
I would say that it depends. Everyone else so far has put things very well.
Use LINQ-to-SQL if you don't mind the fact that your eventual object model is going to very closely mirror your database. There's not a lot you can do with or to a LINQ-to-SQL model if you find that you want to model things differently.
Use EF if you want to potentially use the same framework to point to multiple types of data, or if you'd like to abstract your database model more than is possible in LINQ-to-SQL.
I don't have any data on, say, performance differences between the two models, unfortunately.
I wouldn't say the fact that MS isn't doing a lot of active development on LINQ-to-SQL should necessarily scare you away. Its a very good, very, very basic object mapping solution.