Im working on an application that needs to talk to a database. The application is written in C#. Im quite taken by LINQ and auto generating classes to represent the database and its tables, so first I considered using SQL as .NET only comes with support for LINQ to SQL. Right now Im leaning more to MySQL mainly because scaling the SQL server might get pricey and because the people within my company are more familiar with MySQL, including me. This is where dbLinq comes in. From what I have read dbLinq works fine for simple queries but might break down on more complicated ones. Could you share your experiences in using dbLinq? Should dbLinq still be regarded as experimental or could I expect to use it without a lot of problems?
Thanks, Bas
Edit:
I read that DbLinq is not able to handle more than one foreign key, can anyone comment on whether this is still the case?
I don't know much about dbsql but check out Entity Framework. It allows you do Linq and can be used with MySQL. Check out this SO question for more info on LinqToEntityFramework for MySQL Using MySQL with Entity Framework
I used EntityFramework to connect to MySQL db in my last project. It is gives some minor issues but reduces amount of effort required to code. I am super impressed with it. I had to do Paging and Filtering in that application. Because of EF this was a piece of cake.
This application had very less data (fraction of millions rows). I would like to know how Entity Framework will do in Applications which has large data.
Related
This is quite a long one, but I'd very much appreciate your thoughts and suggestions.
We are busy rebuilding a legacy system which was written in PHP and MySQL and replacing its components with ASP.MVC in C# and SQL Server. The legacy architecture leaves much to be desired and there is a serious issue with spaghetti code, no referential integrity in the DB, unused code and database fields and just generally bad coding.
As much as I'd love to, we can't just rip out all of the old code and replace it. The company needs to stay functional during the development process, so we will need to build new functionality while using the old databases to ensure that their data is accurate at all times. The level of data accuracy isn't real-time, but if we had 2 systems, they would have to be in sync 100% of the time. The old system uses 6 different MySQL databases, all on the same server, running Linux. We will be running Windows 2008 R2 on the new server for the new system and we are planning to use the latest version of SQL Server.
The problem I'm having to solve is: I need to somehow map all of these databases into a consolidated model that we can use through C# to develop the new system on. Once we have moved all the functionality over to C#, we need to port the data into a DB that matches our code model. This DB will be running on SQL Server. I'm not too worried about the migration just yet; my current issue is finding an ORM tool that will allow me to map these 6 MySQL databases into a single, well planned out and designed model that we can use for the new development.
The new model might have additional fields that we would have to store in a new MySQL database until we port the data across at some stage, so the ORM should support easily building entities that span multiple tables and databases.
Is what I'm trying to do possible? Is it viable in terms of effort? Is there an ORM that can do all of this? and what other way is there to maintain operational capacity of the company whilst developing on the system actively?
I have looked at these ORM options:
SubSonic (great, but I think too lightweight for what we are trying)
Entity Framework (looks like I might be able to use this if I use very dirty models with tons of stored procedures for inserts, updates and deletes)
NHibernate (the client does not want us to use this due to bad experiences in the past)
LLBLGen (seems like it can do what we need it to, but long term support could be a concern with the client)
Anything else I should look at? Is there a different approach I could try?
ORMs aren't designed to solve the problem you have. That said, a quality ORM will get you some percentage of the way toward a solution.
NHibernate is the easy choice. LLBLGen would be my second choice. I wouldn't even bother with EF or SubSonic as they are very feature poor compared to the other two and you need decent feature support in your scenario.
You'll likely have to invest a lot of time in writing custom code around your migration requirements. Your use case is not a standard, well traveled path.
For Entity Framework: if you're prepared to maintain one complete set of stored procedures with a static interface (i.e. same signature) you could implement them all in Transact-SQL on the SQL Server box, with linked servers (to the MySQL farm).
When the time comes, you could migrate the data into SQL Server and update your stored procedures.
Basically, design a nice model with nice stored procedures, and as a temporary solution implement any ugliness inside the stored procedures. Once MySQL is out of the way, you can replace the stored procedures with better ones.
SQL Server has a tendency to retrieve the entire remote table when you're running queries against a linked server, so if performance is a concern it might eventuate that all your stored procedures are wrappers around OPENROWSET (see Example A for running a query on a remote server).
I am creating a C# application which will have to upload and read data from a SQL database. In school I learned the raw database calls but I am wondering if there is a free tool which lets me work easier and faster with the database call.
I also need to be sure that none is editing on the same line in the table at the same time so it could be nice if the tool also had something to ensure this.
Hope some of you have some great experiences
Take a look at Object Relational Mappers.
The favourites at this time a nHibernate and Entity Framework, but there are many others.
Creating My Windows Form Application and using ADO.Net as Data Access layer and
SQL server as my Back End with lots of SP's.
Do i still stick to ADO.NET or go to studying FnH or Linq to SQL? Which shall i choose? Or i still stick in ADO.NET?
Can you give me Recommended WebSites on EF or FluentNhibernate for kick of tutorials..
Thanks in Regards
It's really just up to you to pick one - they're all valid technologies.
If you're already familiar with the low-level ADO.NET constructs, and you don't feel like putting the time into learning a different methodology, you can stick with plain old ADO.NET - this is not going away anytime soon.
If you want to start off with a very simple ORM, I would suggest LINQ to SQL. However, Microsoft has basically left LINQ to SQL in the dust in favor of Entity Framework, so if your project has long-term maintenance concerns, LINQ to SQL may or may not be the best choice. It is a really nice, lightweight, easy-to-use framework though...
If you want to learn the latest MS data access technology, you could try Entity Framework. The initial setup is not too bad, but Entity Framework is a beast, so there might be a bit of a learning curve at some point, if you run into something that works differently than you expect, or you want to learn more. EF is fairly full-featured at this point, but it still lacks some of the functions offered by more mature data access technologies like NHibernate.
Finally, if you want to try something different than the Microsoft offerings, NHibernate is a great framework. You're not going to find the entity designers, property pages, wizards, hand-holding, and stuff like that, but that's almost the point of NHibnerate. In Fluent NHibernate, the primary focus can be on your domain code, and less on the database, which makes it very conducive to unit testing. Entity Framework has gotten better with persistence ignorance, but it still feels a bit heavy-weight compared to NHibernate.
In addition to these, there are several other solid data access technologies that you could look into, but I hope this gives you some info to start with.
I'm getting ready to start a C# web application project and just wanted some opinions regarding pulling data from a database. As far as I can tell, I can either use C# code to access the database from the code behind (i.e. LINQ) of my web app or I can call a stored procedure that will collect all the data and then read it with a few lines of code in my code behind. I'm curious to know which of these two approaches, or any other approach, would be the most efficient, elegant, future proof and easiest to test.
The most future proof way to write your application would be to have an abstraction between you and your database. To do that you would want to use an ORM of some sort. I would recommend using either NHibernate or Entity Framework.
This would give you the advantage of only having to write your queries once instead of multiple times (Example: if you decide to change your database "moving from mssql to mysql or vice versa"). This also gives you the advantage of having all of your data in objects. Which is much easier to work with than raw ado Datatables or DataReaders.
Most developers like to introduce at least one layer between the code behind and the Database.
Additionally there are many data access strategies that people use within that layer. ADO.NET, Entity Framework, Enterprise Library NHibernate, Linq etc.
In all of those you can use SQL Queries or Stored Procedures. I prefer Stored Procedures because they are easy for me to write and deploy. Others prefer to use Parameterized queries.
When you have so many options its usually indicative that there really isn't a clear winner. This means you can probably just pick a direction and go with it and you'll be fine.
But you really shouldn't use non-parameterized queries and you shouldn't do it in the code behind but instead in seperate classes
Using LINQ to SQL to access your data is probably the worst choice right now. Microsoft has said that they will no longer be improving LINQ to SQL in favor of Entity Framework. Also, you can use LINQ with your EF if you should choose to go that route.
I would recommend using an ORM like nHibernate or Entity framework instead of a sproc/ADO approach. Between the two ORMs, I would probably suggest EF for you where you are just getting the hang of this. EF isn't QUITE as powerful as nHibernate but it has a shorter learning curve and is pretty robust.
I am working on a personal project as a way of learning more about C# and .NET, specifically creating an application that utilises a database (MS SQL Server 2008 in my case). Whilst I appreciate there isn't always a definitive "right" way of doing things, given the choice between using an old technology/idea or a new one, I would rather use the new one. For example, one of my aims for this project is to learn, or at least familiarise myself with, WPF rather than using WinForms as I have done in the past.
On that basis, I've been muddling around without a great deal of direction with regards to saving data to my database and retrieving it. So far I've managed to get both those working using TableAdapters but I feel like they are the "old" way of working (my basis for this is that they are listed under Visual Studio 2005 on MSDN). Firstly, am I correct in this assumption? If so, what are the newer methods of saving and retrieving data from a database? I would be grateful of any pros and cons each method offers.
I've Googled and searched MSDN extensively but I don't feel like I am using the correct search terms as I have only succeeded in confusing myself.
I have .NET 3.5, Visual Studio 2008 and Microsoft SQL Server 2008 at my disposal.
Any guidance would be much appreciated.
I would agree that TableAdapters, DataSets, DataTables, etc. are the "old" way of doing things.
The "new" way would be Linq-to-SQL, Entity Framework or NHibernate.
Personally, I like to use a combination of Linq-to-SQL along with plain old DBConnections, DataReaders and DTO's where needed.
If you would like a newer way of doing Database access in .NET, I would recommend looking into LINQ to SQL or the Entity Framework.
There are many many many different ways to retrieve data from SQL Server 2008 using .Net.
Table Adapters are not a bad way; they are core to the .Net Framework, easy to get started with and reasonably powerful, although they do not perform quite as well as other options and often require more memory.
Basically Table adapters are good if your data is structured the way you want to view it. If you want to view data in a different way to it is stored you can do this with a table adapter but you loose the ability to write back changes to the database, this is OK if you are just generating a report.
If you want to view and change the data and the data is not in the structure you want to view it you need entity framework so you can query the data to get it into a different format and still have the ability to write any changes back. This is what the call the data from the server the MV to the display the VM