Typed Datasets Are Not Always The Answer

My blog has moved.
You can view this post at the following address:
http://www.osherove.com/blog/2003/5/4/typed-datasets-are-not-always-the-answer-1.html
Published Sunday, May 04, 2003 8:00 AM by RoyOsherove
Filed under:

Comments

Sunday, May 04, 2003 4:00 AM by TrackBack

# ISerializable

ISerializable
Sunday, May 04, 2003 4:00 AM by TrackBack

# ISerializable

ISerializable
Monday, May 12, 2003 6:05 PM by Joe

# re: Typed Datasets Are Not Always The Answer

Don't agree with the answers above.
1. A typed dataset can appear in any assembly in any project. Referencing the typedataset is the same as referencing custom classes - there's no difference.

2. Do you want your business objects holding your business rules. This is not scalabale because you are combining state with logic which means that it's more difficult to distribute your logic across servers. Also you don't have a clear visibility on the dependencies between the logic in your code and the data that drives the logic. The public interface on the data container provides this if you keep your functions outside the business objects.

3. Your schema should evolve independently of the database. The database schema is there to cope with the physical contraints of the database and is used to populate your logical schema - which is the XSD file in your project.
Monday, May 12, 2003 7:08 PM by Roy Osherove

# re: Typed Datasets Are Not Always The Answer

Joe:
Thanks for your comment, however, before coming to any conclusions, read the following article:
"Oops, Datasets *Are* Scalable!*"
http://dotnetweblogs.com/rosherove/story/6434.aspx

which I wrote later after writing this article.
In it I explain why I was mistaken in this article, and how Datasets *can* be used as scalabale objects.
Even so, The sentence "Do you want your business objects holding your business rules" bugs me. Yes, they are business objects. That's their purpose. As for Holding State and rules togather - That's not always the design decision. I can have business objects that return datasets or data readers. All they do is take care of the logic. They do not have to return TYPED datasets though, just plain datasets.... but that's all explained inthe other article..
Tuesday, August 26, 2003 11:23 PM by Ray Jezek

# re: Typed Datasets Are Not Always The Answer

Roy, your right about it being a design decision. We decided to treat out TDS's as DTO's as opposed to business objects, which i think works great and allows you to pass your object "through" business logic instead of being coupled with it. But again it depends on your ultimate architecture... there a lots of ways to solve the same problems. Also, i think updating a TDS is very trivial and shouldn't be seen as a challenge in terms of maint. as compared to custom business entities.
Sunday, January 11, 2004 10:08 PM by J.G. Kurdinov

# You are completely wrong

I'm afraid that you have only explored the peak of the iceberg. As an example you are not considered that the DataSet could be business based and nor DataBase Based. By the way the data access layer is the Database itself with its SP, and not the access to it, that should be in the business layer getting flexibility doing that.
Thursday, January 15, 2004 4:04 AM by Roy Osherove

# re: Typed Datasets Are Not Always The Answer

Kurdinov:
http://weblogs.asp.net/rosherove/articles/6489.aspx
Sunday, June 04, 2006 12:46 PM by STeve

# re: Typed Datasets Are Not Always The Answer

Try using partial classes to inject your business rules.

very powerful feature of partial classes
Sunday, July 09, 2006 1:37 PM by Sharad Singhal

# re: Typed Datasets Are Not Always The Answer

I agree with the original poster's technical lead. I am a proponent of hiding datasets within my business objects. However, My DataGridView needs the dataset to bind to and this defeats all my atempts to make the dataset private to my business objects. Any solutions to this problem ? --Sharad Singhal
Friday, October 13, 2006 4:51 PM by Arnold Kalsbeek

# re: Typed Datasets Are Not Always The Answer

I asume your DataGridView is inheriting from the DataGrid. Well the datagrid looks for some Interfaces like IListSource and IList If you give a good look at the DataSet or DataTable they implement de interface IListSource. So de code: .SetDataBinding(CType(,ListSource),) Will Work. If you Implement the Interface IListSource in your Business objects. Then the code will be: .SetDataBinding(CType(,ListSource),) --Arnold Kalsbeek
Friday, October 27, 2006 3:37 PM by Genaro Kempt

# re: Typed Datasets Are Not Always The Answer

I think that we would have to improve our world with innovations and more design patterns to help development process and "Typed Datasets" do not explores our creativity and do not enriches developed applications. They comes to ease, it does not come to improve.