I am building a forum, and it has got 4 tables: Users, Threads, Comments, Topics.
I established the connection and the pages.. I started using the ADO.net way to insert data and select data..but then I found that to make more complex manipulations i need to know SQL. So I was looking for another way, and I found that I can open Visual Studio 2010, add Linq to SQL file that produced object relational designer. I read about how to write code, and I saw that I simply need to use a using statement with DataContext object with a simple code to update, add, delete rows in the tables.
I wanted to know, what are the advantages of using one way of querying over another?
ADO.NET gives you low level control over your queries. If query speed is going to be of importance, this is where you want to be. If you speed is not very important, but rapid development and an Object Relational Model is, LINQ to SQL is a safe bet.
I would recommend Linq to SQL over ADO.NET though.
Development is rapid and thinking in an ORM way is natural.
If your queries are too slow, using the .ExecuteQuery method will allow you to pass in a sql statement that you have optimized as if you were doing it in the ADO.NET way. I have had much success with Linq to Sql.
Also I would look at Entity Framework. It gives you more control over your objects and how they are implemented, used and handled than Linq.
LINQ to SQL is part of the ADO.NET family of technologies. It is based on services provided by the ADO.NET provider model. You can therefore mix LINQ to SQL code with existing ADO.NET applications and migrate current ADO.NET solutions to LINQ to SQL. The following illustration provides a high-level view of the relationship.
Refer to the following:
ADO.NET and LINQ to SQL
Advantages & Disadvantages of LINQ
Performance of LINQ to SQL over Normal Stored procedure
LINQ-to-SQL and Stored Procedures
LINQ to SQL is great in that it generates alot of the plumbing code for you. But it is basically the same as using straight up ADO.NET/SQL. To do more complex data manipulation in LINQ to SQL you have to know how write complex joins in LINQ just as you would in SQL.
Look into Entity Framework - it might give you a higher level of abstraction that you are looking for.
The two are on different abstraction levels. ADO.NET is the lowest level of data access in .NET. Anything else will build upon it.
Every abstraction should give you power to express higher-level concepts at the cost of lower level concepts.
If I sound like a philosopher it's because it's Friday.
In addition to Entity Framework, you can take a look at NHibernate (another .net Object Relational Mapper). It's been around longer than EF so it's a bit more mature, but it isn't developed by Microsoft if that matters to you.
Related
Can LINQ to Entities entirely replace ADO.Net technology?
What I really want to know is, Is it possible to achieve every features and functionality that ADO.Net provides by using LINQ ? Who is the Boss?
Since you said in your comment that you mean LINQ to Entities, I will answer thus:
LINQ to Entities internally use ADO.Net, so it would be impossible for LINQ to Entities to replace ADO.Net, because it uses it. However I am assuming that you mean to ask if you can use LINQ to Entities in every situation that you could use ADO.Net. The answer is no, you cannot.
There are cases that you would not want to (or could not) use LINQ to Entities. For example if you are in a certain situation where you need better performance for a query, it would be better to use a stored procedure. Generally LINQ to Entities is a better choice when developer productivity has a higher priority than the execution speed of queries. Other cases where LINQ to Entities is not a good choice is when a DB has been poorly designed and does not have a primary key for example.
But the main point I think is this: What has higher priority in your situation? Developer productivity or performance? It is also quite acceptable I think to use both technologies. Complete the project with LINQ to Entities, and if there are performance issues, use stored procedures or ADO.Net.
Also, I would not use LINQ to Entities for large queries, or queries that have many joins, LINQ syntax for joins is not very terse, and may hurt the readability of your code.
#Reddy, it entirely depends on the scenario where you are deciding which technology to use. ADO.NET gives you tuple structure using DataSet at its focus and is used even day compared to ORM like tech i.e. LINQ-Entity. I have refrained to ADO.NET when the prime aspect of the application revolves around record processing, used in the SSIS pipeline but have stuck to LINQ-Entity when I primarily follow Test Driven Development or Domain Driven Development approaches.
1)ADO.NET is the database connectivity technology, so we can use ado.net to do operations with only Databases , but if we get a requirement to get the data from non database datasources like xml,collections etc.. its not possible.
But using LINQ it is possible to get data from many datasources like collections, XML files, Entities, even with Databases also.
2) But if you come to the performance wise ADO.NET is very faster than any other database connective technologies.
3) If you go with LINQ Run time errors can be rectified so bugs will be less ,so reliability increases
so ADO.NET vs LINQ technologies both having their own positives and negative features ,Microsoft given huge amount of featured technologies, so according to the application requirement we need to go with that technology.
I have gone through an article of using EntityConnection, EntityCommands for executing Entity sql queries. But I was unable to understand that Why are we using Entity sql? Why not directly using the Classes and objects for processing CRUD operations on database?
Or If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
Is there any performance difference or something else?
I have already gone through the page http://msdn.microsoft.com/en-us/library/bb738573.aspx. But I want answer in a more simpler way. Can you please answer me?
Thanks
Why not directly using the Classes and objects for processing CRUD operations on database?
That is (should be) the way for almost all operations. But sometimes there is a need for accessing the db more directly and precisely.
If we want to execute sql queries then why we are using Entity Sql , why not directly Ado.net ?
E-SQL will still let you work with entities (instead of Rows). This is much easier and more powerful, consider inheritance for example.
E-SQL is also supposed to be independent of the actual database, ie the same for Oracle etc. I have no experience with this yet.
Is there any performance difference or something else?
It can be used to improve performance, yes. But not automatically.
The main difference
SQL is database dependent query language working on storage (relational) objects - tables / rows
ESQL is database independent query language working on conceptual (EDMX) objects - entities
ESQL was created prior to LINQ. In some scenarios ESQL offers more functionality than LINQ.
I'm opening a discussion here on a subject I couldn't find any answer good enough to be called a final answer: MySQL and .NET.
While I know there is a lot of ways to make this connection, I'm trying to find a list of pros and cons of each approach.
I've been using ADO.NET with the MySQL NETconnector since the beggining of my project, and everything was ok when the database was new and didn't have many records. But now I'm facing a situation where the number of records grows exponentially, and I found other way of querying against the database, which is the ODBC connector. Using the ADO.NET + NETConnector solution I had my O/RM and didn't have to write my queries, while ODBC makes my code look awful now (since I didn't switch completely to ODBC, I have Linq queries and plain SQL queries inside my code).
Is there any solution (free or not) where I can have both an O/RM without the need of writing SQL queries myself and the speed of ODBC?
What you should be doing is using the MySQL ADO.NET Connector and storing your queries in the database in the form of stored procedures. Version 6.0 of the MySQL connector also supports The Entity Framework. If you are interested in using the Entity Framework, check out this link which describes how to set that up.
NHibernate
Update to Comments
NHibernate Proxy Generators
It is a byte code generator for your object model that allows NHibernate to perform lazy loading and other operations. The link provided explains the benefits.
Castle and LinFu are two different implementations of those Proxy Generators.
While NHibernate does not have coincide documentation all the information on how to use it, is on the internet. This could be a barrier to usability for some people though. I understand more about NHibernate because of my past experience with Hibernate.
I have heard that Linq query write once can be run on SQL and MS Access database too. Is it right or wrong?
For example I want to write queries once regardless of database type like currently I'm using MS Access database and later then if I wish to move on to SQL Server then I don't want to change my queries. Is this possible??
It depends in part on the queries. For simple queries (select, where, orderby) you should be fine, but there are a lot of implementation-specific details.
For example:
taking a First on a set you haven't explicity ordered : LINQ-to-SQL is fine with that, LINQ-to-Entities will fail
using an Expression.Invoke to build a gnarly custom expression : again, LINQ-to-SQL is fine, LINQ-to-Entities will fail
using things like UDFs - in addition to LINQ-to-Entities not supporting it, your RDBMS might not support it
with "Astoria" (LINQ to data services), there were some scenarios around .Where(predicate).FirstOrDefault() vs .FirstOrDefault(predicate) - which are semantically identical, but IIRC only one works (in Astoria)
My point is; it might work, but you do need to test against the specific implementation.
LINQ-to-SQL will only work with SQL server. Linq to objects will work on most any collection, but you lose the deferred execution.
If you use Entity Framework, you can find/buy several provider for different data sources.
As soon as you have enough abstraction over the entity context, you can use any LINQ construct to build your queries. But keep in mind that not all providers support the same operators and functions. You will still have to test the complete application during a DBMS change.
Basically, you can use Linq to Objects and work with any dataset.
If you want to save your logic and specific - I recommend you to use Devart LinqConnect.
Also, you can read more about simultaneous Oracle and MS SQL usage in given article. Approaches will be the same for LinqConnect.
I am trying to leverage ORM given the following requirements:
1) Using .NET Framework (latest Framework is okay)
2) Must be able to use Sybase, Oracle, MSSQL interchangeably
3) The schema is mostly static, BUT there are dynamic parts.
I am somewhat familiar with SubSonic and NHibernate, but not deeply.
I get the nagging feeling that the ORM can do what I want, but I don't know how to leverage it at the moment.
SubSonic probably isn't optimal, since it doesn't currently support Sybase, and writing my own provider for it is beyond my resources and ability right now.
For #3 (above), there are a couple of metadata tables, which describe tables which the vendors can "staple on" to the existing database.
Let's call these MetaTables, and MetaFields.
There is a base static schema, which the ORM (NHibernate ATM) handles nicely.
However, a vendor can add a table to the database (physically) as long as they also add the data to the metadata tables to describe their structure.
What I'd really like is for me to be able to somehow "feed" the ORM with that metadata (in a way that it understands) and have it at that point allow me to manipulate the data.
My primary goal is to reduce the amount of generic SQL statement building I have to do on these dynamic tables.
I'd also like to avoid having to worry about the differences in SQL being sent to Sybase,Oracle, or MSSQL.
My primary problem is that I don't have a way to let ORM know about the dynamic tables until runtime, when I'll have access to the metadata
Edit: An example of the usage might be like the one outlined here:
IDataReader rdr=new Query("DynamicTable1").WHERE("ArbitraryId",2).ExecuteReader();
(However, it doesn't look like SubSonic will work, as there is no Sybase provider (see above)
Acording to this blog you can in fact use NHibernate with dynamic mapping. It takes a bit of tweaking though...
We did some of the using NHibernate, however we stopped the project since it didn't provide us with the ROI we wanted. We ended up writing our own ORM/SQL layer which worked very well (worked since I no longer work there, I'm guessing it still works).
Our system used a open source project to generate the SQL (don't remember the name any more) and we built all our queries in our own Xml based language (Query Markup Language - QML). We could then build an xmlDocument with selects, wheres, groups etc. and then send that to the SqlEngine that would turn it into a Sql statement and execute it. We discusse, but never implemented, a cache in all of this. That would've allowed us to cache the Qmls for frequently used queries.
I am a little confused as to how the orm would be used then at runtime? If the ORM would dynamically build something at runtime, how does the runtime code know what the orm did dynamically?
"have it at that point allow me to manipulate the data" - What is manipulating the data?
I may be missing something here and i aplogize if thats the case. (I only have really used bottom up approach with ORM)
IDataReader doesn't map anything to an object you know. So your example should be written using classic query builder.
Have you looked into using the ADO.NET Entity Framework?
MSDN: LINQ to Entities
It allows you to map database tables to an object model in such a manner that you can code without thinking about which database vendor is being used, and without worrying about minor variations made by a DBA to the actual tables. The mapping is kept in configuration files that can be modified when the db tables are modified without requiring a recompile.
Also, using LINQ to Entities, you can build queries in an OO manner, so you aren't writing actual SQL query strings.