I'm trying to familiarize myself a bit more with database programming, and I'm looking at different ways of creating a data access layer for applications. I've tried out a few ways but there is such a jungle of different database technologies that I don't know what to learn. For instance I've tried using datasets with tableadapters. Using that I am able to switch data provider rather easily (by programming against the interfaces such as IDbConnection). This is one thing I would want to achieve. But I also know everyone's talking about LINQ, and I'm trying to get to know that a bit better too. So I have tried using Linq to Sql classes as the data access layer as well, but apparently this is not provider independent (works only for SQL Server).
So then I read about the Entity Framework (which just as Linq to SQL apparently has gotten its share of bashing already...). It's supposed to be provider independent everybody says, but how? I tried out a tutorial to create an entity data model, but the only providers to choose from were SQL Server/Express. Just for learning purposes, I would like to know how to use the entity framework with MS Access/OleDb.
Also, I would appreciate some input on what is the preferred database technology for data access. Is it LINQ still after all the bashing, or should you just use datasets because they are provider independent? Any pointers for what to learn would be great, because it's just too much to learn it all if I'm not going to use it in the end...!
the only providers to choose from were SQL Server/Express
The .NET Framework only includes EF providers for SQL Server and SQL Server Compact. If you need to access another DBMS, you need to install a third-party provider. For instance, there's a free provider for SQLite, with designer support. There are also a few (commercial) providers made by Devart, for various DBMS. As far as I know, there are no EF providers for OleDB or ODBC...
I really like the metaphor from Scott Hanselman: "I'm not a plumber, but I do know what an S-Bend is."
Personally, I think you should have a working knowledge of all the variety of ways to access data.
ADO.Net, EF, Linq2Sql, txt files, xml etc etc etc.
Have a look at the Nerd Dinner and the Music Store samples. See the way they access data (how do they do Unit Tests, Mocking framework, IOC etc)
Regarding data providers, personally I would avoid Access. It is just as easy to get a Sql Express or Mysql installation running and looks better on your resume.
(For what its worth, this question discusses setting up mysql for EF.)
Related
I am designing a simple C# WCF service using ASP.NET 4.0 and hosted on IIS7, which will be used by .NET and Java web applications and desktop applications to extract data stored in various databases (both local and remote). I am starting to learn how to use VS2010 and WCF after working for a few years on VS2005 and asp.net web services, so am somewhat of a noob to WCF but know a bit about web services and Visual Studio.
Does anyone have opinions on what the best approach would be in terms of project/class/file setup in Visual Studio 2010 to do this, seeing as how I want to maximize code re-use and minimize development time yet still have the ability to connect to the different databases? I have a WCF Service Application project for the service, and have generated a WCF Client to use for testing using svcutil.exe, but now I'm at the point where I need to start writing database access layer code (or "model" code for MVC if that's the design route I need to go down).
Any help appreciated, thanks!
Each of the databases will have their set of nuisances while integration. The first thing you need to start with would be to design your model in more of OO (Object Oriented) fashion than relation DB way. Once such a model is created, you need to implement mapper layer/classes that would map data from a relational form to a OO format. Then for each DB you need to write some data access code. The amount of code you write for data access may well depend upon the tools\technologies you use. You could look into Entity Framework or NHibernate or other such ORMs to decrease the code required to access data. But keep in mind these ORM mappers may require their own set of tweaks to work well with MySQL, Oracle, SQL Server.
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'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.
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/