The Old .NET Questions Forum - Vanilla Objects vs. DataTables

这篇2004年的帖子讲到了“使用Datatable实现业务层”，有个回复说这并不是一个好主意。

Vanilla Objects vs. DataTables

What is the preference? I've done two small projects (< 50k LOC) and one time I used objects that would be loaded by datareaders, etc.  The second time I decided to try and use DataTables as the "business object layer".  It seemed to work reasonably well, but this *is* a simple project, so I was wondering if there were disadvantages.  I simply had a list of Factory classes that would return dataviews depending on what you asked for from a globaly shared DataTable.  Thoughts and comments always appreciated. 

vince
Thursday, April 22, 2004

Ooh, ooh, I know! Pick me!
Vince,
I just posted a similar question here earlier this week - http://discuss.fogcreek.com/dotnetquestions/default.asp?cmd=show&ixPost=3396&ixReplies=5
There wasn't a whole lot in the way of definitive experience but there are a number of links to some great articles. Visit http://www.searchcsla.com to search through the MSN threads related to Rockford Lhotka's CSLA framework.
Hope that helps.

Matt
Thursday, April 22, 2004

There are two problems using DataTables as the business layer:
1. They tend to reflect your database architecture.
2. They aren't type-safe.
You can overcome objection #2 with strongly typed datasets. However, tying your upper layers to your database architecture is a pretty bad strategy. And if you're going to all the trouble to create a "virtual" datatable layer on top of the real database architecture, you might as well have used objects in the first place.
For any relatively simple application, using data tables is going to be fine, because refactoring (either to new data table structures, or to an object model) is not going to be very expensive.
For complex applications, though, you'll find that not only is the cost to switch too expensive, you're pretty much guaranteed you're going to have to make it any way. Complex business logic rarely wraps itself neatly around single tables in the database.
I should like a shill for this book, because I recommend it constantly, but it's really the best book I've seen for discussing these kinds of situations, with the trade-offs and the various potential solutions. Pick up "Patterns of Enterprise Application Architecture" by Martin Fowler.

Brad Wilson (dotnetguy.techieswithcats.com)
Friday, April 23, 2004

I'll definatly be getting that book then, Brad.  I've seen lots of others talk about it, so I might as well.  Now, why does your datatable have to reflect your database design?  I've actually built my system to use DataTables more as "Views" then as actual representations of the database design.  The main reason I decided to go with DataTables was the fact that it made databinding just so dang easy.  Thanks for your advice guys.

vince
Monday, April 26, 2004

"Now, why does your datatable have to reflect your database design?"
It doesn't, but it tends to. Even with views of joined tables, it still looks like your tables, and those views would become a lot harder to construct if you radically changed your data storage architecture.
Good luck... :)

Brad Wilson (dotnetguy.techieswithcats.com)
Tuesday, April 27, 2004

The Old .NET Questions Forum - Vanilla Objects vs. DataTables