Have Geek Brain

How to choose a data access method in ASP.NET MVC?

I have been programming in C # 2.0 WinForms for a while now. I am starting to get into ASP.NET and the new MVC framework and new C # 3.5 features. I only read a little about LINQ to SQL, but did some test applications to try. In my WinForms applications, I usually had some kind of data access layer and wrote all the SQL myself. Of course, if something can do this CRUD for me, I'm all for it.

I followed the tutorials on the website www.asp.net/mvc and did both Entity Framework example and LINQ to SQL example. So far, they both look pretty similar. LINQ is more like SQL, but Entity Framework is more like C #.

My questions:

  • Is one method better than the other?
  • What are the advantages of one over the other?
  • Can you see the SQL that is generated when using any of the methods?
  • Since I'm new to the ASP world, web developers relying on one side?
+1


source to share


2 answers


2: LINQ-to-SQL has the advantages of being simple (but still well-designed), but the disadvantage of being simple; -p

  • LINQ-to-SQL only works on SQL Server (Entity Framework connects, third-party LINQ-to-SQL flavors such as DBLinq cover some other providers).
  • The Entity Framework supports a great abstraction between the data model (storage) and the object model - LINQ-to-SQL is literal table / column => class / property [| field]
  • LINQ-to-SQL is actually more "complete" in what it does:
    • EF does not support UDF
    • EF doesn't support things like calling sub-expression (for custom expression trees)
    • EF does not support some "obvious" methods such as Single()

    • EF lacks some of the TSQL optimizations that LINQ-to-SQL uses

Basically EF is a bit more "v1" (or even "v0.9") at the moment. However (and, importantly). EF most likely has the correct next version in .NET 4.0 and so on, where as LINQ-to-SQL will see a lot less change. This is still supported , but Microsoft famously chose Entity Framework as the flagship product (rather than co-evolving both products essentially in each other). You need to think about long term plans.



I'm very happy to use LINQ-to-SQL at the moment , but EF is in the long run ... so I use a repository, etc. to hide some of the implementation details of gory - a bit of a leaking repository, but pragmatic .

3: With LINQ-to-SQL, assign TextReader

to dataContext.Log

; Console.Out

works well - or I have one that writes to trace.asax. With EF ToTraceString .

4: I suspect it breaks down a lot in complexity. People using SQL Server with simple models, or who are happy to have a storage model that shines in the object model, tend to be using LINQ-to-SQL at the moment (from what I can see). People with more complexity and other databases tend to use NHibernate; -p And then some EFs. I am wondering how this will change when EF is released in .NET 4.0 ...

+7


source


Use the one that works best for you, your team, and your project. It doesn't matter how you access the data, as long as you access it.



You can use plain old ADO.NET if you like.

0


source






More articles:


All Articles