>The main reason that I don't advocate putting all the DataAccess stuff in the DataSets themselves is because of the fact that I believe a DataSet should be a disconnected entity. A DataSet class is the object that I use to pass the data between the back-end and the front-end. The DataSet class has no idea *where* it's data comes from and has no idea how to save that data. That part of it is all handled in the DataAccess class.

So your doing something more along the lines of DAL.Update(DataSet)?

That would still be more intuitive to me than a table adapter.

>Now, it sounds like you want to have a different architecture. You want to use Biz objects as the mechanism for data transfer between back-end and front-end. That's fine, a lot of people do it that way. I'm in the other camp though.

I don't really know what I want yet, I was just out googling <g>

It seemed like a common setup.

Do you not use BIZ objects?

I haven't yet, but I do have one application that might benefit from the concept.

>Perhaps someone who advocates the Biz object style of data transfer and UI data-binding can chime in here and give you some pointers. I'd hate to recommend anything along those lines simply because I don't do it that way and consequently my advice in those matters would just be off the top of my head (and probably be wrong) and would not come from any experience I would have had in the 5+ years I've been doing .NET.
>
>I hope that doesn't sound like a cop-out. <g>

Nah that's fine, stick to what you know.