9

I would like your opinions regarding "DataSet Designer" and DAL (Data Access Layer) best practices. I use Visual Studio 2010 Framework .NEt 4.0.

For my understanding "DataSet Designer" allow me to create automatically strictly Typed-DataSet with DataTable and Adapter, this consist in DAL directly in Visual Studio 2010.

I would like to know: - If in real scenario "DataSet Designer" is working well, or is better write Custom Business Object. - If exist other new solution introduced in .net 4.0

Thanks for your support! :-)

GibboK
  • 71,848
  • 143
  • 435
  • 658

10 Answers10

8

I have to work with typed datasets and it is a nightmare. If you have an option never use them. Everything is better.

Ladislav Mrnka
  • 360,892
  • 59
  • 660
  • 670
  • so what do you recommend using? – Brian Vander Plaats Aug 30 '10 at 18:43
  • 2
    If you don't need complex mapping: POCO + standard ADO.NET or Linq-To-Sql. If you need complex mapping NHibernate + POCO or EF4 + POCO. DataSets are technology from .NET 1.x. There were some updates in .NET 2.0 but those updates make them even worse. – Ladislav Mrnka Aug 30 '10 at 20:00
5

With the advent of the .Net 4.0 framework and the introduction of LINQ to SQL, I've been adopting a customized DAL of strictly written business objects. We experimented with Entity Framework briefly, but ultimately concluded that it is very similar to DataSets in that the auto-generated code, while handy, is just too bloated with extra junk that we ultimately didn't use.

We've found that writing LINQ into our DAL and extracting data pulls into our custom classes, we are able to streamline our data access and control the usage of the data functionally. It has been a very handy process, but it has taken a little bit for the junior developers to grip onto it.

Joel Etherton
  • 37,325
  • 10
  • 89
  • 104
  • +1 for briefly explaining that one can be critical about EF. Indeed, it has (quite some) drawbacks. Personally, I still use NH, much more flexible and no impact on the DB at all. – Abel Aug 30 '10 at 13:38
  • 1
    You should look into the new "Code-First" Entity Framework. It's like using Fluent nHibernate only with EF. It's very lean IMO. The only downside is that it's still in CPT (currently 4), but very cool to play around with. Check out the EF blog for more info: http://blogs.msdn.com/b/adonet/archive/2010/07/14/CTP4CodeFirstWalkthrough.aspx – TheCloudlessSky Aug 30 '10 at 13:39
  • @TheCloudlessSky - I'll give it a look. We're still fishing around for a new standard since we're in between major projects, so thanks for the read. – Joel Etherton Aug 30 '10 at 13:50
4

I would suggest a ORM like Entity Framework or Nhibernate.

Data Sets smells too much to database way of thinking and I personally had a lot of problems working with them. They just get broken quite often and throw weird errors that are hard to troubleshoot.

Some other related questions you may find interesting

What are the advantages of using an ORM?

ASP.NET DataSet vs Business Objects / ORM

Community
  • 1
  • 1
Claudio Redi
  • 67,454
  • 15
  • 130
  • 155
2

Use ADO.NET Entity Framework, which is where the future of Microsoft's ORM is going. Or, consider an open-source one like NHibernate...

HTH.

Brian Mains
  • 50,520
  • 35
  • 148
  • 257
2

At my company we've been using Typed DataSets for a little while now, and have had a generally positive experience. I understand that many people don't like DataSets, and there are certainly newer data access tools out there, but since you asked about a real-world scenario, here are some of my requirements and findings:

  • Need to be able to read SQL Server, MS Access, and FoxPro data sources
  • SQL Server access is only through SPROC calls (not my choice)
  • Relatively easy to learn, especially to developers new to ASP.NET

I've personally explored low level ado.net access, typed datasets, linq-to-sql, and simply writing custom data access classes. I have not looked at the Entity Framework yet, as the version included in VS2008 seemed to have some mixed reviews, and I did not have access to VS2010 until just recently(I do plan to review EF sometime this year yet).

We chose to use Typed DataSets because they seemed to offer faster development against SPROCS and we found a very comprehensive tutorial by Scott Mitchell on the asp.net site: http://www.asp.net/data-access/tutorials.

As to our experience thus far, it has mostly been good. The DataSet designer generates a huge amount of code even for small number of Tables (<20). Making changes in the SPROCS has caused a few headaches, but I'd like to be shown a tool that would make this easier.

One thing you might try to make your decision easier: Come up with a small domain problem like a customer edit page or order entry page, and implement it multiple times using a variety of technologies. It takes some time to do this, but it is a good way to learn and you can compare the technologies for yourself. We did this and it seemed to help a lot.

Brian Vander Plaats
  • 2,257
  • 24
  • 28
1

I will personally prefer custom business objects with their flexibility but its more work. Also look at with Entity Framework and Linq To Sql. Entity Fx has got a lot more flexibility in .NET 4.0. This article should get you started on Entity Fx.

VinayC
  • 47,395
  • 5
  • 59
  • 72
1

If anything I think you should look into Entity Framework. There are lots of great tutorials out there to get you started.

TheCloudlessSky
  • 18,608
  • 15
  • 75
  • 116
1

I personally agree with Joel Etherton, conditionally.

If you have a small enough project that even with EF's bloat you're still not looking at too much shenanigan-code, I would say the expediency it offers is worthwhile. However in larger codebases, it can become a lot to get your hands around so much bloat.

The other benefit to EF vs older style business objects which goes unmentioned though, is with EF implementation you will probably get easier upgrades to newer .NET versions taking advantage of benefits in the next .NET without having to rewrite a bunch of code by hand. (This can also be a double-edged sword as upgrading to new .NET with EF may affect the behaviour of your dal as opposed to a hand-written dal is less likely to be so affected.)

That said, I agree with Joel Etherton, write the simplest smallest dal you can implementing LINQ, the dal is always too important to make overly-complex whenever it can be avoided.

Jimmy Hoffa
  • 5,909
  • 30
  • 53
1

If you do not want to waste you time do not learn DataSets. Study general concepts of object-relational mapping, their pros and cons. Look at projects like Hibernate for Java or Doctrine for PHP. Approaches behind DataTables and DataSets which provide just wrapping of database objects is over. Your framework should guide you to design you domain model, not the database schema.

Petr Kozelek
  • 1,126
  • 8
  • 14
0

NHibernate. Especially if you are using Oracle.

code4life
  • 15,655
  • 7
  • 50
  • 82