Separate Table Adapters from DataTables

[Paul Daly]

I'm trying to come up with the architecture for my senior project.
It's a web application with a SQL Server backend. I would like to use
a multi-tiered approach with the database, a data access layer, a
business logic layer and a user interface layer.

The structure of the solution is as follows:

- Solution
+DAL (Class Library)
+BLL (Class Library)
+UI (Web Project)

From what I understand, the UI should not have access to the DAL,

except via the BLL. I want to enforce this by not adding reference to
the DAL in the UI. However, the businesslogic layer is returning a
datatable that was defined in the DAL. I'm setting the data source of
a gridview to that datatable. This requires that the UI know
something about the datatable defined in the DAL.

Can I separate the datatables from the table adapters? Can I add a
business objects layer from which the DAL, BLL, and UI can reference?
This way the UI can reference the BLL and the BOL, but not the DAL?
The DAL and BLL can reference the BOL as well?

The problem is that I'm only familiar with using the wizard for
creating the table adapters, and the wizard automatically puts the
table adapters with the custom datatables. How can I separate these?

Are there any other solutions to this that I'm overlooking?

Thanks in advance for your help!

Paul Daly

 

[Guest]

Sorry for the double post... It didn't look like the first one went through.

 

[RobinS]

Check out Deborah Kurata's book, "Doing Objects in VB2005". It shows how to
separate your layers so the UI only sees business objects, no data access
stuff; the business layer deals with the data access layer to get the data
and pass it back to the UI. This book shows an excellent example of how to
write a WinForms app and do this. I think it could be easily adopted for a
web application.

It's in VB, but most of it pertains to C#. There are a couple of things I
haven't figured out how to do in C# -- mostly the customized user settings
stuff -- nothing in regards to the business objects.

You can also check out Rocky Lhotka's books, but I found Deborah's book to
be easier to comprehend through example.

Robin S.
--------------------------------