I am hearing a lot of rumours that Linq2Sql is not going to be supported any more in the next version of .net. I like Linq2Sql a lot and find it very easy / lightweight to work with. I can understand some of the problems people have had with it (ppl used to nhibernate...) but used correctly I think most problems can be solved. I currently use it in all my projects now and I would hate to see that it isn't going to be supported any more.
So list the disadvantes you see with Linq2Sql
If there were another version of Linq to SQL, here's my feature wishlist:
Things I actually wanted whilst building my last Linq-to-SQL project (and had to work around manually in most cases)
Many-many associations
Better visual designer (including a "refresh table" feature)
Control over cascade delete/update/SET NULL that doesn't involve hacking the XML
Specific mappings for culture/string comparisons into SQL COLLATE statements (e.g. specifying whether passwords should be case sensitive or not, rather than relying on the default collation of the underlying database.)
Things I might want but haven't actually needed yet:
Support for ordered collections (persisting lists to the DB so they are automatically retrieved in the same order they were persisted)
LINQ to SQL can certainly be fixed. But so long as the ADO.NET team is in charge of it, I seriously doubt it will be.
If it gets open sourced I think it will be a force to be reckoned with. But as it stands, it is a dying technology.
One of the biggest disadvantages I see in L2S is that it is a really hassle to use it in disconnected scenarios; send off a serialized version of an entity to another and try to "merge"/update it when you get it back and you will see it's shortcomings. If the .Attach() functionality had worked for such scenarioes, L2S would have been quite nice.
--larsw
First and foremost, people are losing interest in it since it will not be developed any further, and Entity Framework will go forward instead.
LinqToSQl works and is pleasant to use, but EF will overtake it sooner or later.
The ORM purists would prefer if it was easier to set up LINQ to Sql to use an object model that is external to the LINQ to SQL data layer. This can be done in Linq to SQl, but it's a manual process that's far from the default configuration.
Related
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'm recently migrating to Linq2Sql and all my future projects will be using Linq2Sql. Having said that, I researched a lot on how to properly plug-in Linq2Sql in application design.
what to put at what layer ?
How do you design your repositories and business layer services ?
Should I use DTOs over Linq2Sql entities on interaction layer ?
what things should I be careful about ?
what problems did you face ?
I did not find any rock-solid material that really talked about one single thing and everyone have their own opinions. I'm looking forward to your ideas on how to integrate/use Linq2Sql in projects. My priority is maintenance[it should be maintenable and when multiple people work on same project] and scalabilty [it should have scope of evolution].
Thanks.
I have been using linq to entities for the last two and half years on production applications and I can say it has been a really nice experience... but that doesn’t means you should do everything with Linq.
I am going to try to give you some answers to your questions,
I think you should ask first what kind of application you want to create; once the scenario is clear you will have an odd idea of number of transactions or queries you are going to perform against the database (or repository).
Linq could be extremely useful to abstract data access, context and entities handling, but everything comes with at a cost. Objects will be created with a cost and you really need to think about this.
If your application has a ‘nice-not-too-heavy’ data access Linq will be the perfect tool to save time for your application.
If your application is entirely based on data extraction or processing, Linq will be great as well.
If your application is handling huge blocks of data (check your application) you will need to do something else to avoid creating a bunch of objects that might be useless.
What does that means? You need to know what a smart data access means... and that is leave SQL to work for you (in the case of SQL); if you are going to do lots of joints, cross information and stuff, create stored procedures that creates the data result for you and then get it using Linq or SqlCommand or SqlDataAdapters, etc...
What to put at what layer?
Since Linq gives you the data access abstraction you can pretty much place your code where the business logic demands it. There are tons of good practices of how to structure your code; Linq (as any other entity framework or data access libraries) will fit in the right spot.
Avoid whenever is possible direct linq expression in your controls (asp.net has lots of controls with linq data sources), instead wrapped your ‘query’ with a service class that can be instantiated by your code or controls as an object data source.
What have I found?
Pure Linq is not always possible on big applications or projects (so you will end up with many things in linq and some in previous more simple solutions to access your repositories) but will help you to save time.
Implementing stored procedures is a MUST if you want to deliver great quality applications.
Hope this comment helps.
Cheers.
I'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.
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.