1

I've been reviewing examples on the web of 3 layer design and I've noticed that most samples return either datasets or data tables. The thing that is confusing me is what if you would rather return a generic list of type so you can utlize properties or methods from within the type your list is based on? As example using a Name property that concats various fields in a specific way depending on the data, if the List is bound to a control on a form then the Name property can be used as the datafield. If you would want to accomplish the same thing when using a dataset or table, you'd have to return the data from the database to acheive the same (I try not to use datasets or datatables so I'm probably very wrong about this statement. :) )

The part that is really confusing me is about resusing code, to me it seems the only way to reuse code is to retrieve the data into either a dataset or datatable and then loop through the data and add it to a List, is this generally the best practice for 3 layer or is there a way to do this without datasets and datatables.

The example in the link below demonstrates in essence using datasets or tables and then adding it to an object but I'm forced to ask if this is the best practice?

http://www.codeproject.com/Articles/36847/Three-Layer-Architecture-in-C-NET

Thanks

obb-taurus
  • 847
  • 1
  • 7
  • 12
  • 2
    Use `Datasets` or `DataTables` for small projects only. They don't scale well and have many limitations. The `dbConnection` class in your link is a bad example since it don'i dispose/close connections and other disposable objects. – Tim Schmelter Jan 12 '13 at 19:11

3 Answers3

2

Using DataTables is a specific dotnetism. The reason behind it is that they contain metadata about the structure of the data, which lets DataGrid (and other such components) display the data automatically without using reflection or so. My guess is this is amongst other things a heritage of the MS Access approach to RAD, where the intent was enabling "business people" to create apps by generating the user interface directly from a SQL schema, essentially doing the opposite of a tiered design. This heritage then seems to have leaked into the hivemind.

There's nothing wrong about using "plain" data structures, as long as you're willing to give up the RAD features, and the trend lately seems to have been to get rid of this tradeoff too. (For instance with Web Forms' strongly typed data controls, and MVC's model binding features.)

Also, speaking more generally, Code Project articles from before MVC was established are not really a good source of wisdom on general software architecture.

millimoose
  • 39,073
  • 9
  • 82
  • 134
0

What you should carry your data on depends entirely on your needs.

If you retrieve data from the DB and bind it to a datagrid, datasets might give you the perfect solution. If you want some other method where data tracks its own update status you should look into Entity Framework. If you retrieve data and send it through a web service for cross platform or cross domain processing you need to load your data onto some other serializable classes of your own.

Take a look at the article below. It is a little old and targeted at EF4 but it summerizes pros and cons of different strategies very well. (There are three articles in the series, I suggest you read them all)

http://msdn.microsoft.com/en-us/magazine/ee335715.aspx

e-mre
  • 3,305
  • 3
  • 30
  • 46
0

I think the samples you're finding used data tables and datasets because it's a simple way to show 3-tier design. Now days Entity Framework has largely replaced the "data access layer" mentioned in the sample.

Before entity framework when I wrote a data access layer I would return a generic list that I built from the database. To run an update, delete, or insert I would pass an object in as the parameter to the methods, then use the object's properties as the values in the sql statement. I preferred doing it that way for the reasons you mentioned but also because it allowed me to change the object definitions or db schema (or even use a different db all together) independently of each other.

allen.mn
  • 467
  • 3
  • 11
  • I haven't dived into the realm of the Entity Framework so I'm stuck at the moment using a DAL. Would you have a sample of the way you used lists? – obb-taurus Jan 12 '13 at 19:57
  • @obb-taurus Same difference really. Entity Framework mainly returns `IEnumerable`s of your own model objects, that's close enough to `List`s for your purposes. – millimoose Jan 13 '13 at 01:04
  • A sample would need dozens of lines of code and this really isn't the way to do it anymore. I was essentially writing an ORM (object relational mapper) but there are several ORMs available now that will save you lots of time and be less buggy than writing one yourself. The best practice for getting a generic or strongly-typed collection from a database is to use Entity Framework, LINQ to SQL, or NHibernate. – allen.mn Jan 13 '13 at 22:35