Hi

There seems to be so many different kinds.

• raw ADO.NET
• LINQ-to-SQL
• Entity Framework
• Typed Datasets

Currently I am using Typed Datasets. I like them because I got the GUI for the dataset and I can and my sql is in its own place.

The thing I don't like about them is since they are typed if you try to Join some tables together and they return some stuff that the set does not expect you can do that.

So anyways I seen now is 2 different MVC books they been using linq to sql. Now looking a bit into it I am not sure if I should use it or not.

I am not sure what the advantages over a typed dataset.  I am guessing I still could do a 3 tier arch with linq to sql with the linq to sql gui thing being the data layer?

Now I also heard that linq to sql is dieing and not going to be further developed. I am not sure if this is true or not since like I said all these new MVC books seem to use it.

They also use something called the "Repository Pattern" I am kinda confused about that one too.

First they say something like this

"...using a repository pattern can make it easier to change data storage implementations in the future, and it can help facilitate unit testing an application without requiring a real database." -NerdDinner

Ic the unit testing part. I been thinking about that one and how I would test that if I were using datasets. I guess this pattern could be applied to a typed dataset too.

The thing I don't get is "change data storage implemntations". What does that mean does that mean I can change from linq to sql (to) Ado.net?

I don't see that since they are written different. So I just don't understand it.

So I am not sure if I should use this or stick to what I am using or what. It's tempting to use since all these MVC books use it but if it is dead/dieing then I dont' know.

Also does anyone know any good Repository Pattern tutorials? Thanks

Hi,

A lot of what you see written today is based on LINQ to SQL, which was available before Entity Framework (EF).  Since there are many applications already written with LINQ to SQL, it isn't going away any time soon, but should be considered a legacy technology at this point. The way forward is via EF, which is where MS is putting their primary data technology focus on for today and in the future. I think it would be better to start all new work with EF.

Joe

My two cents:

1. Do not worry too much on adapting the newer technologies even when they are not needed in your project. Newer technologies like LINQ are not promoted as replacements to existing techniques (like SQL) but merely are alternatives to do the same thing. You can still use SQL instead of LINQ with no issues at all.

2. Repository pattern is a subset of Provider model, and I suggest you use it only when you know that your application might need to connect to different databases in future (like Oracle, MySQl etc apart from MS SQL Server). If you are sure that this wont be the case, then no need to use a provider or a repository pattern. Keep things simple.

3. Again point #1 goes with MVC too, no need to use unless you absolutely need it.

4. An application using typed datasets will work fine too as long as it is programmed correctly. MS is releasing technologies quite furiously but that does not mean you need to imibibe each and every one of them. Just keep your basic architecture strong and things will fall in place automatically.

HTH,

Vivek

My standard answer is that LINQ to SQL, EF and related ORM-like technologies are great for small scale sites where you don't care about performance.  They can also be very useful in rapid prototyping.  For large-scale sites or sites where performance is important, you will be much better off using ADO.NET.

RickNZ:

My standard answer is that LINQ to SQL, EF and related ORM-like technologies are great for small scale sites where you don't care about performance.  They can also be very useful in rapid prototyping.  For large-scale sites or sites where performance is important, you will be much better off using ADO.NET

I somewhat agree with this statement, although you can make LINQ perform better but that requires extra work. And if not programmed properly, LINQ can hog CPU and decrease performance considerably.

As of now, I would avoid using LINQ for enterpise scale applications but that again is my personal preference.

You can make LINQ perform better up to a point.  However, LINQ doesn't support async queries, command batching or multiple rowset results, so any serious application will be much faster and more scalable without it.

• LINQ To SQL - you can use your own business objects but only inheritance strategy is table-per-hierarchy. So it fits well for simpler databases. I'm using it for projects with simpler object models.
• Entity Framework - should also support table-per-subtype inheritance strategy but support for custom business objects is missing (it will be there with version 4.0). I don't want to use it in real projects until support for custom business objects is implemented.
• NHibernate - supports almost everything you need to write your applications. This is my main choice right now.

Do you know if NHibernate supports async queries, command batching, table valued parameters and/or multiple rowset results?

Async queries - you can make everything asynchronized way on .Net. Command batching and multiple rowset results are there. I am not sure about table valued parameters. Of course, you can do also database specific things right through the mapper.