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.
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.
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'm just starting to look into using LINQ for my database (and XML, and data object!) needs, but need to decide on which database to go with. I've been reading Pro LINQ, and it says that currently, LINQ in .NET 3.5 only supports SQL Server. I have done some googling, and have found references to using LINQ with MySQL and PostgreSQL (my other two DB options), but they are refer to DLinq, which I understand to be the predecessor of LINQ to DB.
I've read interesting and informative comparisons of the three databases here and here, but am still torn. I do not have any in-depth database experience, so it's important to be able to get the software installed and configured easily, or at least be easy to figure out how to compile a list of steps to configure it. I definitely want to have transactional support as well. But most importantly -- I want to use LINQ.
I'd like to hear what everyone here is using, whether it's SQL Server because LINQ supports it natively, or the other two with some additional component for LINQ support that I haven't yet found.
We use devart's dotConnect provider for Linq-to-Oracle and have been very pleased. They try and make the functionality match Linq-to-SQL as close as possible, which seems to be what you're looking for.
They have providers for:
Oracle
MySQL
PostgreSQL
SQLite
SQL Server
From a cost perspective, it's an excellent deal I'd say, just pay for developer seats, no server licensing.
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.
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/