Problem
In the past, our development team decided to create a new enterprise application and decided to use "Linq to SQL" since the Entity Framework "sucked". (Not my opinion!) They used Visual Studio 2008 and the EF wasn't part of the default setup but required an additional add-in. So the decision was made to use Linq to SQL to access the database. As a result, we now have multiple projects around a datamodule class library containing a DBML and L2SQL entities...
Needed
It is now clear that those developers were wrong. Some moved on to other companies and a few new ones are included in this project. (Including me.) And we would like to use the Entity Framework instead. Preferably version 4 with .NET 4.0... This will allow us more flexibility with our data and we're hoping to include some inheritance in several of the entities, making the code easier to read and nicer to use.
Question: How to...
So, how to migrate from "Linq to SQL" to the Entity Framework 4 without the need to rewrite much of our code?
Manually. There is no other way and if you don't have integration test suite for all projects using the data module you should not start with any migration until you write those tests because many linq queries which worked in Linq-to-Sql doesn't work in Linq-to-entities (and not only Linq queries).
Generally that migration is wrong idea. It looks like you want to make a migration just because you want to use another technology. What real business value will be added by this effort? EF and Linq-to-entities offers some additions but it is in many ways worse than Linq-to-sql. There is no need to touch code which works unless you have some real business requirement which will make this necessary. Especially migrating to EFv1 would be really stupid move. You can use .NET 4 with your current code without any problems because Linq-to-Sql is part of .NET 4 as well.
If you ask me the former developers made a good choice when they made selection between EFv1 and Linq-to-Sql.
Related
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 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.
I am working on a framework which will provide some basic functionality for a number of applications which our company is going to develop.
The framework will come with a basic database schema which will support this functionality.
Developers using the framework will be expected to extend the database schema with their own tables. Future versions of the framework will be shipped with update scripts to make any changes required.
What do you think the best way of accessing the database would be - both from within the framework and in the application itself?
I'd like to use either LINQ-to-SQL or the Entity Framework.
Taking LINQ-to-SQL, for example, I guess I could distribute a DBML file with the framework, allowing the application developer to extend it and provide a reference to the data context back to the framework?
Although it presents some new details, this is still just a versioning issue.
As you develop your system, modifications to the database must be versioned along with modifications to the code. Updates to your system should be an executable package including those database scripts and your data access assembly.
Users that wish to upgrade to the next/latest version must apply the package, which will execute all the database scripts to update the database, and replace the assembly that contains your data access layer. You may want to consider making your DAL a separate assembly for distribution purposes. You could use dependency injection to plug your DAL into your core system.
Depending on the complexity of the system, my fallback would be LINQ to SQL. It performs better overall and is simple to implement. If you expect your object model to get fairly complex, and performance is not a major factor, you may want to go with EF now rather than having to switch later. That's a cost-benefit analysis between performance, complexity, and ease of development.
HTH
I hope that you're using MS Sql in the back-end (though you are if you have Linq To SQL as an alternative).
I have some experience using L2S and some using Entity Framework. In my opinion EF is the better choice because it gives you a better approach towards OR/M and more control over the database objects.
It has full support for LINQ and also for Entity SQL which will give you more power when you need to write complicated queries.
Do NOT think about using EF with MySQL. More about that here
Im on to design my Data Access for a new solution i create. That solution though contains Compact Framework Device Application and libraries besides Desktop. All .NET 3.5. Desktop will handle all Data Access basically. I need the Data Objects to have in CF too, Desktop will communicate with SQL and then with Mobile and give the appropriate data...
I love LINQ, and more i love LINQ 2 SQL. There is a lot of hype out there and i don't buy internal Microsoft politics about recommending EF. For now EF is too heavy and too complex for someone to choose it besides it still evolving and EF 4 will have major changes when it comes in a few months. But i cant wait for months to create a project as every developer in here, i want something now! After that said i want to use LINQ 2 SQL, my problem is that i cant just copy the generated dbml and use the generated classes. I don't need the DataContext cause i don't intend to use CRUD or any operations on a database with the Mobile App. i Just want the Objects. Anyone ever came in a situation like this? The whole point is not to write all classes representing the tables by hand. Cause i need them for further LINQ to Objects manipulation.
Basically an ORM supporting CF would do the job! But i don't know any incompatibilities i would meet.
I've been able to modify SubSonic 3.0, the db4o/Mainsoft port of System.Linq.Expressions from the Mono project after adding the missing Queryable sources, and Matt Warren's IQToolkit on Codeplex to provide a L2S equivalent on the CF.
This is about what it takes, though, since Linq expression trees are not supported on .Net CF 3.5.
I was able to use the DbEntityProvider/DbEntitySession and AttributeMapping/XMLMapping imported to Subsonic from IQToolkit to provide better entity and table-to-class mapping support.
L2S works great with the compact framework. You can't use the drag-and-drop designer, though. You'll need to run SQLMetal.exe yourself to generate the classes for you.
SQLMetal.exe: http://msdn.microsoft.com/en-us/library/bb386987.aspx
Example with Northwind compact: http://blogs.msdn.com/sqlservercompact/archive/2007/08/21/linq-with-sql-server-compact-a-ka-dlinq-over-sql-ce.aspx
Another example, with lots of pictures: http://pietschsoft.com/post/2009/01/Using-LINQ-to-SQL-with-SQL-Server-Compact-Edition.aspx
You could use DevExpress persistent objects (XPO) on compact framework. I have used it before but found it to be somewhat slow for my purpose (data collection application).
The reason that you cannot find much of this on the compact framework is that speed is usually so important for device apps, that data access code is usually done manually.
I don't know if you can create objects from an already existing database with XPO.
This is one good option generating from dbml file plain POCO classes working with LINQ 2 SQL. Not tested yet but seems promised.
http://www.codeplex.com/ULinqGen
Have you checked out Kea - Linq for Sql Compact & Compact Framework?
http://kea.codeplex.com/
I would like to know what are the principal diferences between "ADO.NET Entitiy Data Model" and "Linq to SQL Classes"? What is the best choice to work with?
I couldn't find any document on the internet explaing that and everything I know is that we can use both, "almost", in the same way.
Linq To Sql is not being actively supported by Microsoft anymore.. They have picked the Entity framework has 'the way for the future'. You can google and verify this.
Here's your friendly neighbourhood SO topic with all the good bits
Update: Hmm.. it seems that MS has taken a step back from the infamous declaration. But the message is still not clear with respect to the future of L2S.
as of .NET 4.0, LINQ to Entities will
be the recommended data access
solution for LINQ to relational
scenarios.
We also want to get your feedback on
the key experiences in LINQ to SQL
that we need to add in to LINQ to
Entities in order to enable the same
simple scenarios that brought you to
use LINQ to SQL in the first place.
That pretty much reads 'phasing out' to me. I may be guilty of reading between the lines though.. there may be hope after all... behind all the 'on-the-fence' answers
ADO.Net team blog : Update on LINQ to SQL and LINQ to Entities Roadmap
ADO.Net team blog : Clarifying the message on L2S Futures.
http://damieng.com/blog/2008/10/31/linq-to-sql-next-steps
EF classes are not persistent-ignorant. They inherit from a base class that adds a unique entity key and change tracker. This can make disconnected environments more of a pain with EF than the object generated by L2S.
This is what I can tell from personal experience (which may not be the whole story):
The learning curve for LINQ to SQL may be slightly less steep than for ADO.NET Entity Framework. Personally, I also feel that LINQ to SQL is a bit more lightweight.
Both frameworks are getting updated in the next version of the .NET framework (version 4).
If you include the features for .NET 4 then Entity Framework appear to be the more feature rich framework. Microsoft seems also very commited to this framework.
Visual Studio has quite strong support for both frameworks. For instance, if you create an ADO.NET Data Service in your project it will discover both your LINQ to SQL and Entity Framework classes.
Entity classes in the Entity Framework are derived from a specific base class in the Entity Framework. Some may consider this a showstopper for using the Entity Framework.
I find both frameworks surprisingly easy to use and I would suggest anybody interested in these technologies to play around with them. Create a .NET project of choice in Visual Studio and add both LINQ to SQL classes and an Entity Framework model connected to whatever database you have access to. Then try out both frameworks by doing things like CRUD operations etc.