John,

>Yes, but I'm just getting started with C# so I'm not sure I fully appreciated the beauty of the technique. Sounded like it was mostly for when you were working with stored procedures, which I am not doing yet, so I don't think I fully understood it.

Our particular little utility *did* work just with Stored Procs (because we do all our DataAccess *only* through Stored Procs), but the same concept can be applied while using SELECT statements.

>For my first attempt at this, I created a windows control library project and added a class based off System.Data.DataSet I then just used the provided dataset designer to design it as a typed dataset.

OK, similar thing ... the Designer creates an .xsd rather than using a utility. In our utility, it's simply a matter of getting a DataSet by calling a Stored Proc (you would execute SELECT commands) and then creating an .xsd by using the DataSet.WriteXmlSchema() method.

>I assumed I would need to override the connect string at some point, but have not gotten that far yet.

Yes, and here's part of my point ... the connection string shouldn't even be *in* the DataSet class. A connection string should have absolutely *nothing* to do with a DataSet. The connection string belongs in the DataAccess layer and, IMHO, this is separate from the DataSets.

>I'm also curious as to how LINQ will fit into all of this.

I haven't played around enough with LINQ. I think, from my limited knowledge of it, that LINQ to SQL is not going to be very helpful ... at least from the standpoint of the architure we use. LINQ to DataSets is where I will see a benefit, but again, I haven't really had the chance to do much with it.

>And how you are designing biz objects so they can still easily be bound to the form.

We don't. We use DataSets for databinding, not biz objects.

~~Bonnie




>>John,
>>
>>Yep, I'm back home. But working through some deadlines right now.
>
>Thanks for the reply, I have time so no problem if this thread drags out a bit. We are getting into basic design philosophy of the data access layer, which since most of my apps are data driven, I really do need to understand.
>
>>Since Kevin said he was gonna post something, I figured he already had some blurb written up on this topic. And since I've got to sit down and think through the best way to describe my thoughts on this topic, which I haven't gotten around to doing yet, I've been waiting to see what Kevin has to say, so I can add my 2 cents if I needed to (which I probably wouldn't need to do). He told me he was putting something on his blog, but so far he hasn't.
>
>I'm looking forward to seeing it when he does.
>
>>Did you see what I already *did* post about using an .xsd to define your DataSets?
>
>Yes, but I'm just getting started with C# so I'm not sure I fully appreciated the beauty of the technique. Sounded like it was mostly for when you were working with stored procedures, which I am not doing yet, so I don't think I fully understood it.
>
>For my first attempt at this, I created a windows control library project and added a class based off System.Data.DataSet I then just used the provided dataset designer to design it as a typed dataset. I assumed I would need to override the connect string at some point, but have not gotten that far yet.
>
>>I'm not sure if you're looking for info for DataSets or DataAccess? I guess by using a TableAdapter you're tying the two of these concepts together, so I suppose you need direction for both.
>
>They do seem tied together to me. My understanding of all of this is probably minimal at best.
>
>>Unfortunately, I don't think I have anything I've already written that describes the whole process ... using a Typed DataSet class from an .xsd, filling it in your DataAccess class, then passing it back through the layers to the UI layer ... but, that's basically the flow of everything.
>
>Hopefully Kevin will come up with something that explains it further. I'm also curious as to how LINQ will fit into all of this. And how you are designing biz objects so they can still easily be bound to the form.
>
>No rush, and thanks for the reply.