Designing a Data Access Layer (DAL) with remoting in mind

[Rupes]

I am trying to learn ASP.NET while writing a system in it and am
feeling a bit overwhelmed.

I have just read most of a book on ADO.NET. I will need to write a data
access layer for this system and it is more than likely that the data
access tier will have to be on a separate application server.

It would seem to me that it would make sense to pass a disconnected
object such as a DataSet back and forth between the web server and
application server using remoting. Since a DataAdapter is not user or
session specific this should not cause any problems.

As far as I can make out the only way to make use of the features of a
DataSet is to store the DataSet in the users session area. Then the
changes can be applied to the DataSet (not clear on how this is done)
and then the DataSet could be sent to the application server and a
DataAdaptor used to write the changes to the DB.

There are some places where I would like to use a DataReader to display
read only data. But this is a connected object. So if I understand this
right if I bound it to a control every call to read the next record
would go across the wire to the object on the application server?

Can anyone offer some insight into these issue or designing a DAL with
remoting in mind? Any links to good articles/examples also appreciated.
Thanks
Rupes

 

[John Saunders]

I am trying to learn ASP.NET while writing a system in it and am
feeling a bit overwhelmed.

I have just read most of a book on ADO.NET. I will need to write a data
access layer for this system and it is more than likely that the data
access tier will have to be on a separate application server.

It would seem to me that it would make sense to pass a disconnected
object such as a DataSet back and forth between the web server and
application server using remoting. Since a DataAdapter is not user or
session specific this should not cause any problems.

It's also possible to do remoting by using a "standard" data access layer
pattern. You can then remote the "instance" of the data access layer.

John Saunders

 

[RG]

Thanks John,
That makes sense. Unfortunately I am not familiar with any DAL
patterns. The article I posted a link to above mentions the
Model-View-Controller pattern. I will do some more research.
Rupert

 

[Sahil Malik]

Rupes,

As many people as many opinions - and I am going to offer one that maybe
even contradicts the ones you have received so far.

I've used remoting heavily in a windows application/webform based scenario
that dealt with a system using appservers and we used to remote datasets all
over the place in framework 1.1 - and I had nothing but problems. The two
environments I used; one had 650+ app servers, and the other had lesser
(10-15ish), but a much larger database (400 gigabyte+) and a more complex
application in general. I donot like remoting datasets, and I especially
donot like serving them as webservice parameters or responses.

Here are my reasons ---

a) Bloat - dataset, even if you use binaryformatter is serialized as XML,
not only that, it is serialized using XMlSerializer - which is hella bad.
This apparently has been addressed in 2.0 using DataSet.RemotingFormat
property.
b) Timezones - Dataset insisted on doing a double shift in time everytime a
strongly typed ds was sent over the remoting wire between 2 machines in
different timezones. This again was addressed in 1.1 using DataSetSurrogate
(search microsoft KB) - which had it's own issues (default values/bugs/and
super picky about accept changes etc.). This inherently was thanks to the
xmlserialization - which again might be addressed in 2.0/ I haven't tried.
c) Efficiency - Datasets are huge objects. True they are disconnected, true
they are easy to produce, but they are still maybe more than what you need
for most of your objects. You have datatable true .. but then it might make
sense to have an arraylist at best.
d) Strongly Typed datasets - and how they handle nulls - is annoying at
times.
e) Strongly typed ds - changes - and manual modification nightmare.

In short, I would recommend that if you have the time and resources, invest
in creating business objects by hand. Create a datalayer, create a business
layer, and have the business objects/business layer be remotable. Create a
stateless datalayer, and put it on a CAO enviroment using remoting - bingo -
you've just created a very scalable and maintainable app.

A further elucidation - presentation layer requests an objecft from the
business layer - business layer calls data layer or layers to get datatable
info that it then uses to hydrate a serializable business object - that then
can be remoted easily to the client. This now can be put even as a
webservice, or as a remoting implementation - this I feel would give you the
best maintainability in a large enterprise environment. The most awesome
part here is that DataSet is disconnected, so it can be passed between
business layers once it is pulled out of the d/b. That way you can create a
very pluggable/testable system. Especially in .NET 2.0, you can fill a
dataset or datatable using a datareader - that gives you best of both worlds
especially if reading is most of your operations (versus
update/delete/insert).

It can be argued that maintaining these biz objects is a royal pain - but
again I digress for 2 reasons.

a) You put validation in biz objects - so you don't have to put validation
in each layer - duplication / out of sync / and don't tell me it won't end
up being in each layer because the dba doesn't trust that the UI got the
right parameters.
b) The VS2005, you have a BEAUTIFUL class designer - and a whole refactoring
engine - making maintaining these classes a matter of point and click pretty
much.
c) You give this class diagram or the generated xml documentation to your
tech writer and bingo - half your work for the data dictionary is done (well
half because database could be different in structure from the biz objects)
....

In other words, this approach pays off many dividends.

Anyway, just my 2 cents.

- Sahil Malik
http://dotnetjunkies.com/weblog/sahilmalik