As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am reading about Linq. Please explain to me how Linq, DLinq and XLinq are different.
Linq is the base language extension which lets you query data collections using sql-like syntax. The big advantage is that it is written next to your code in the Visual Studio environment so the concepts of sql data access have been promoted to first level language constructs. This means you get all the intellisense and other cool advantages of working in VS.
So like I said, Linq is the basic technology. You can use this to query virtually anything. In plain vanilla form you can just access data like arrays
DLinq is what linq to sql was called when it was in development.
Linq to sql is a way of mapping your database to a data context and then you can use linq to access your tables in your database and make changes. It is a pretty cool technology but unfortunately it is out of date now and is being "discontinued" by Microsoft in favour of Entity Framework (which is Linq to Entities).
When I say discontinued what I mean is this: they have said they will do more features after asp.net 4.0 but they are going to put main development emphasis on Entity Framework and lots of Microsoft apps are going to be converted to use Entity Framework.
XLinq as you might have guessed by now is a way of querying Xml files with Linq.
Here is a tutorial introducing it.
Both DLinq and XLinq are just extensions for Linq:
Linq is a programming model that introduces queries
as a first-class concept into any Microsoft .NET language
DLinq is an extension to Linq that allows querying a database
and do object-relational mapping.
XLinq is an extension to Linq that allows querying XML documents,
as well as creating or transforming XML.
Official MSDN link for linq where you can get anything you want.....
LINQ is a set of extensions to the .NET Framework that encompass language-integrated query, set, and transform operations. It extends C# and Visual Basic with native language syntax for queries and provides class libraries to take advantage of these capabilities.
Where as other are flavor of the Linq you can also create you own if you want.
Dlinq is for the SQL to linq
Xlinq is for the Linq to XML
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I have dome some seriously complex projects using the traditional WebForms and Stored procedures. Recently, however, I did a project using MVC and Entity Framework and I liked they way it works with Entity framework. They way its lets you deal with entities in object oriented manner...Its awesome. The project was not very complex. Just about 12 -15 tables.
We all know that WebForms and stored procedures are more mature and hence reliable technologies of doing thing. With my knowledge EF is still evolving. It doesn't even have the very basic "Unique Constraints". Although there are work around for things, It make's me think twice before starting a project with EF.
What I want to ask is, If I want to start another huge and complex project, can I chose to go with MVC & EF ? Is there any risk of hitting a dead end ?
Personally I use EF and MVC for every one of my new projects. I have yet to encounter a drawback. On the contrary, I find MVC far better to work with. With regards to your stored procedures, they are still and always will be more efficient than running TSQL ad-hoc.. just replace your normal ADO.NET code with EF and continue using the stored procedures. As for unique constrains, you still do those in the DB itself. More info here:
Unique constraint in Entity Framework
and here:
Does Entity Framework 5 support unique constraints?
Also, check this link for using stored procs and ad-hoc TSQL queries with EF: http://www.asp.net/mvc/tutorials/getting-started-with-ef-using-mvc/advanced-entity-framework-scenarios-for-an-mvc-web-application
There is little risk of using EF and MVC for complex projects. If you use EF, you can still call stored procedures or execute dynamic sql queries (not that you should). EF gives you options. There maybe more risk of not using it. Don't forget SO is built with MVC.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am a beginner to .Net. Recently I am working on a small practice project in which i want to interact with SQL DB using Datasets in VS .net 2008. Kindly suggest me few readings regarding Typed Datasets.
If you prefer to work with datasets (and ado.net in general), I would recommend Microsoft ADO.Net Core Reference. The book is dated now, but in my opinion, so is using datasets. Either way, you can't beat that book in my opinion. The follow up book, which covers ADO.Net 2.0 is more modern and done almost as well as the original (though the original will teach you more about how everything works).
you can google these things. however check the below links
MSDN Documents
Creation of Typed DataSet
A search in google for DataSet Examples C# turned the following results:
DataSet examples C#
Are you sure you want to use DataSet? There are a better techniques now for accessing and manipulating data.
Update:
Depending on your needs there are other ways to access data.
If you need speed - you will probably need to use SqlDataReader.
If you need ease of use, you may skip the more "core" ways of accessing data and use Entity Framework.
Retrieving data with Sql Data Reader
Getting started with Entity Framework
The difference is that SQL Data Reader is the most native way of accessing data. It it uses something like cursor you iterate over.
Entity Framework on the other hand is a fully featured OR/M solution for Microsoft Visual Studio, you basically tell Visual Studio where your data is and it will generate the data classes for you. From there - you just use those classes. It is really easy to use but it uses reflection under the hood which makes it a bit slower than the Sql Data Reader.
Hope this helps!
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Why we need LINQ in C# , if we can do anything using ADO.net. Then what is the need of LINQ queries?
Are they optimized enough than ADO.net? Which is best one to use?
Personally I think that Linq greatest strength is that it optimizes the developer. It's beauty lies in freeing the developer query over variety of data sources using the same query language extensions.
You can answer how many classes are in the System.Web namespace or how many customers in our database are in Ottawa using virtually the same syntax.
Of course that comes at a cost but isn't that what optimization means?
We can't tell you why you need LINQ. That's for you to decide. Also there is a difference between LINQ and what you perceive as LINQ. LINQ does not solely mean querying SQL. LINQ is built into the compiler to translate query statements into method calls, and there are many providers that you can use with LINQ, Linq-to-Sql is one of them (I believe this is what you are referring to), Entity Framework is another, Linq-to-Objects is another, Linq-to-Xml etc.
Linq-to-Sql (and EF) are ORM frameworks used to map database objects from your database domain to your application domain. ORM frameworks can greatly reduce development time whilst providing automatic data loading, property mapping, relationship aware models, etc.
You can do all of this with vanilla ADO.NET too, but you have to roll your own. My question to you would be, is it feasible for you to use an ORM framework in your project when you consider a) your existing codebase, b) development deadlines, c) maintainability.
Linq to Sql (which I assume is what you are referring to), is useful because it provides a convenient abstraction.
It is far simpler to write a linq query than to write sql, and then hydrate an object manually.
Composability: allows you to compose queries dynamically using different code paths without resorting to complicated and fragile SQL string concatenation
Type Safety: The classes generated by LINQ to SQL or Entity Framework are strongly typed, and so type checks are enforced at compile time.
Staying in the Object Oriented world: you program in an object oriented language, why not access data in an object oriented fashion? Navigation properties allow you to get all the orders of a customer without writing a single query: cust1.Orders.
Readability: LINQ, using query comprehension or extension method syntax, is much more readable then embedding a mismatched DSL such as SQL into existing .NET code.
Rapid Application Development (RAD): With L2S/EF and LINQ, you can hit the ground running. You can get a database-connected application up and running in no-time.
Abstraction: Using a single tool, LINQ, you can access various types of data, and even create a query across multiple domains: Various databases, objects, XML, 34 more...
Database Generation: if you thought an O/R mapper only maps a database to objects, you thought wrong - it can work the other way too. EF can automatically create a database based on the classes you've created. That can be a reasonably good starting point, or even good enough for small systems.
DataTable provides you a cache that
can be re-enumerated without DB
roundtrip while LINQ to SQL results
need to be explicitly cached with
something like a ToList()/ToArray().
Identity caching in DataContext aside,
the L2S code is closer to enumerating
a DataReader. Although DataReader does
not allow you to re-enumerate and
requires another ExecuteReader, the
impact of reenumerating L2S query is
the same – another roundtrip to DB.
http://blogs.msdn.com/b/wriju/archive/2008/07/14/linq-to-sql-vs-ado-net-a-comparison.aspx
LINQ to SQL vs ADO.Net
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm looking for a good ORM for an upcoming project.
The database will have around 1000 to 1200 tables, and it will be in Both SQL Server and Oracle, which will be used depending of customers enterprise needs.
Also a few part of the project will work with WCF services.
I want a designer or something like that.
Good support of LINQ.
Acceptable performance.
I have tried DataObjects.Net but it doesn't have any designer. We can't code all that tables nor use code generator. And I'm not sure if DataObjects.Net supports switching database.
Also I'm familiar with EF4 but it can't support both databases together, and switching databases manually(modifying the edmx file) is such a pain in ... for maintenance job.
Thanks in advance.
Edit: Seems OpenAccess and LLBLGEN Pro have designer but I don't have experience with them.
I would still vote for Entity Framework v4 - EF4.
After all:
you can have multiple EDMX files, no problem - one for SQL Server, one for Oracle
you could put those into their own class library, and then load or, or the other, or both, if needed, at runtime (e.g. by using the Managed Extensibility Framework or something of your own)
you can easily target those EDMX files at databases using connection strings - really not hard at all
OpenAccess can also do the job for you. You could use the multiple .rlinq files and assembly-per-database approach as suggested with Entity Framework. The benefit I see for you would be the support you will get from Telerik as there is quite a chance for you to hit a rock or two while developing a solution of such proportions.
Given this information I would suggest to look into NHibernate (and/or fluent-nhibernate).
The item you will have to look into is performance. This depends heavily on the nature of your application. 1,000 to 1,200 tables sounds massive, so I'd recommend to definitely run a number of meaningful performance tests (in addition to all the other tests) before you finalize the decision.
Edit: In fact the better starting place for NHibernate is nhibernate.info (Thanks, Justin!).
I think you'll need to pick your ORM and designer tool separately. For example, go with EF and LLBLGEN, or NHibernate and CodeSmith, or NHibernate and LLBLGEN, etc.
I would also suggest NHibernate but the place to research it is definitely NHForge:
http://nhibernate.info/
Here is the high-level feature overview (including LINQ):
http://nhibernate.info/doc/nhibernate-features.html
There are a few designers available, including LLBLGen Pro:
http://nhibernate.info/doc/commercial-product-ecosystem.html
NHibernate 3 is in alpha now but I know that it is already being used in production a few places. That might be the best way to go for a new project.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
If starting a new project what would you use for your ORM NHibernate or LINQ and why. What are the pros and cons of each.
edit: LINQ to SQL not just LINQ (thanks #Jon Limjap)
I have asked myself a very similar question except that instead of NHibernate I was thinking about WilsonORM which I have consider pretty nice.
It seems to me that there are many important differences.
LINQ:
is not a complete ORM tool (you can get there with some additional libraries like the latest Entity framework - I personally consider the architecture of this latest technology from MS to be about 10 years old when compared with other ORM frameworks)
is primarily querying "language" supporting intellisense (compiler will check the syntax of your query)
is primarily used with Microsoft SQL Server
is closed source
NHibernate:
is ORM tool
has pretty limited querying language without intellisense
can be used with almost any DBMS for which you have a DB provider
is open source
It really depends. If you develop a Rich (Windows) desktop application where you need to construct objects, work with them and at the end persist their changes, then I would recommend ORM framework like NHibernate.
If you develop a Web application that usually just query data and only occasionally writes some data back to the DB then I would recommend good querying language like Linq.
So as always, it depends. :-)
Errr... there's LINQ for NHibernate.
Perhaps what you mean is which to use:
LINQ to SQL
NHibernate
I prefer NHibernate.
LINQ to SQL is fairly lightweight, but it's a little bit more tightly coupled to your data structure, as opposed to NHibernate which is pretty flexible in terms of the types of object definitions that can be mapped to your table structures.
Of course that's not to say that LINQ to SQL has no uses: this very website uses it. I believe that it's quite useful to get up and running in small applications where the database schema is not as massive.
Start with NHibernate is a bad idea. It shows a good performance only with ably settings. Try to use EFv4 for large projects and L2S (maybe 3rd-part products) for small and medium size. These products are more convenient and flexible than NHibernate and allow you to start quickly.
not a complete list
LinqToSQL
Pro:
better tool support
good linq provider
easy to start with when db-schema == classes -
Con:
not flexible (ie db-schema != classes)
only supports MS SQL Server
no cascading (save, update ... doesnt cascade to referenced objects)
NHibernate
Pro:
a lot rdbms supported ootb
feature rich
very flexible for almost all corner cases
open source
Con:
not so easy to start with
not from MS
there are many tools, but you have to search for
Between the 2 ORMs
i would choose LinqToSql if:
db-schema == classes
only ever use MS SQL Server
shop only allows MS-Products
i would choose Nhibernate if:
richer objectmodel
legacy db-schema
DB other than MS SQL Server or support multiple
performance critical (i think NH has more features to optimise performance than LinqToSql)
NOTE: this is my personal view. I deal mostly with (crazy) legacy dbs and complex ETL jobs where the object model helps a lot over SQL.
I don't use (or even know) NHibernate, I just want to give my testimony: I use LINQ to SQL since about 2 years with MySQL and PostgreSQL databases (using DbLinq on Windows, using Mono on Linux and Mac OS X).
So LINQ to SQL is NOT limited to Microsoft products.
I can confirm that LINQ to SQL is very well suited for small and medium projects, or large projects where you have the absolute control of the database structure.
As the reviews indicate, LINQ to SQL has some limitations that make it an inappropriate tool when there is no direct mapping between the database tables and the entity classes.
Note : LINQ to SQL doesn't support many-to-many relationships (but this can be easily achieved with a few code lines).
The main drawback of NHibernate is the inability to make use of method calls. They cannot be translated to SQL. To circumvent that, you have to recreate expression trees which is difficult to do.