Remember a while back - before there was .NET? We passed around Recordsets. The nice thing about a Recordset was that it was the container which the data was returned to you in and it marshaled itself, if necessary.
If you want to follow a similar model, then you have two choices. As Graeme pointed out you could use DataSets. The act of using xsd.exe creates a typed DataSet which is essentially the same as a DataSet, just with custom props for your domain. You could also use DataTables, which are actually closer to the Recordset. If you are just pulling data out the database, I recommend the DataTable over the DataSet. The DataTable is a little more lightweight and has all the features you need. And if you need to use it in a DataSet later, you can just add it. The DataSet is good for putting a bunch of data together and setting up relationships. So you may want to consider using a DataTable for returning the data in your first question, but then return a DataSet for your second question. The DataSet would contain two tables and relationship between the two. One thing to consider is that generally you want to keep the number of times you copy and/or process the data to a minimum. So using a DataSet/DataTable are nice if that is how you are ripping the data out of the database. But what if you are using a DataReader? I think Fowler [1] has some interesting thoughts on this. He makes the distinction between the domain object and the data transfer object. Your question seems to be more about what to use as a data transfer object and the DataSet and DataReader seem like a natural migration from WinDNA to .NET. For what I am working on at the moment, I am not using either DataSets or DataTables. I am using the xsd.exe tool to take my schema and create classes. I use these classes to move data between the tiers. I am still able to represent reasonably complex relationships between the data (like the DataSet). The classes abstract the actual technology I am using to get the data from the source; keeping in mind not every source is a database and I don't always get back a DataSet (e.g. DataReader). Lastly, you can marshal these classes rather nicely by just marking them as Serializable (by the way these work better when you are implementing WebServices see [2]). While this may seem like more work, I think the schema should be the defacto way of defining data. Unfortuanately, until the tools get better (although VS.NET and XMLSpy are a good start), it requires some expertise other than just C#, VB etc. Since many clients I have spoken/worked with don't have (or don't want <frown /> ) much experience in schema they seem to be choosing DataSets and DataTables. Hope this helps, curt [1] http://www.martinfowler.com/isa/dataTransferObject.html [2] http://www.pharossoftware.com/docs/Strongly Typed Web Services.doc ----- Original Message ----- From: "Graeme Foster" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, April 28, 2002 5:24 AM Subject: Re: [DOTNET] Best way to pass object between tiers > You can use a DataSet to pass your data around between tiers. You can > use xsd.exe to generate DataSets which expose Product and ProductData's > properties. Also, because you get DataSets back from your queries, ou > don't have to do any of the packaging you are talking about. > > I'm sure I've seen using DataSets for this purpose suggested in several > places in MSDN, but here's one page to get you started: > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide > /html/cpconadonetarchitecture.asp > > "Because the native serialization format of the DataSet is XML, it is an > excellent medium for moving data between tiers making the DataSet an > optimal choice for remoting data and schema context to and from an XML > Web service". > > HTH, > G. > > > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of > Anye M. Sellers > Sent: 27 April 2002 23:57 > To: [EMAIL PROTECTED] > Subject: Best way to pass object between tiers > > > This isn't specifically a .NET question because it > could apply to any OO development but since I'm > developing in .NET I'm interested in the answer > specifically as it pertains to .NET. > > If I have a class (we'll call it Product) that has a > number of scalar properties and a data access class > (we'll call it ProductData) that extracts the Product > data from the DB and then passes it back to Product, > is it better to stuff all the properties into a > Hashtable or ArrayList to send back to Product for initialization, or is > it better to initialize the Product from within ProductData and pass it > back? > > On a similar vein, if I have a class ProductCategory > that contains properties of its own including a > collection of Product objects, is it better to pass > Product and ProductCategory objects between the > business and data access objects or to again parcel > them up as a collection and then pass them? > > I'm not sure if there is a resource advantage to using > the Hashtable/ArrayList as opposed to > Product/ProductCategory, is there an inherent size > difference between Collection classes and custom > classes, and would this even matter if both the > Product and ProductData objects resided on the same > machine? > > Sorry if this sounds scattered; I'm trying to come up > with a coherent standard to use in these situations > that I can document for my team. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
