P
pcoppney
We are in the middle of a project that requires both a web GUI and web
services. We have elected to go with a 3-tier (data, business,
presentation) model using typed datasets as the data layer. We are not
using either the sql data source or the object data source on the page,
just rolling our own, old school style. The customer(s) will are all
business partners with reliable and fast connects and there is no
expectation of ever having a consumer direct option.
We are posting this since we have been unable to find any real examples
of this type of implementation and are looking for help in poking /
filling the holes. Who knows you may be looking for an example, so
here goes.....
Data Layer
Straight vs2005 generated typed datasets for all updatable data access.
For read only reporting and display data access we will use untyped
datasets. We have not had much success with data readers so we will
shy away from them if possible. You can generate a strongly typed
dataset so we won't bore you with the details.
Business layer
Accepts requests from pres layer or web service layer and interacts
with the data layer. Any necessary validation, conditional
enforcement, or other business logic is checked / applied. In many
cases this is just a pass through if we have done a good job with
required fields, getting and setting nulls for value types, and client
side validation. In others, especially calls from the web services,
there will be a bit of processing going on in the Biz obj. This layer
is not creating a business object from the typed dataset, only
interacting with the datasets as they pass through.
Presentation layer
Is "Aware" of the typed datasets, but has no idea where they come from,
and is limited to reading data from them and plugging data into them.
All data access must go through the biz layer, even if just a pass
through or simple lookup. The pages are smart enough to do most of the
required field checking and input validation, however any conditional
biz logic or other complex enforcement is left to the biz object. We
are currently storing the typed datasets in the viewstate. As
mentioned before the users all have reliable connectivity. We don't
load any data that we are not willing to put on the page so there are
no data security issues. All of our updatable datasets are dealing
with 1 or 2 rows data so they don't really bloat the viewstate all that
badly.
We have implemented several pages and so far it seems to be working.
The typed dataset is living up to the billing of reducing both design
and run time errors due to the increased use of intellisense. The
performance so far is great and we are already reaping the benefits of
reusable code blocks, both in the data and biz layers.
So there it is - shoot it down before it multiplies. We think we are
on the right track - but since we built the track - what else would
we think? I would be glad to provide some code samples upon request
Thanks in advance.
services. We have elected to go with a 3-tier (data, business,
presentation) model using typed datasets as the data layer. We are not
using either the sql data source or the object data source on the page,
just rolling our own, old school style. The customer(s) will are all
business partners with reliable and fast connects and there is no
expectation of ever having a consumer direct option.
We are posting this since we have been unable to find any real examples
of this type of implementation and are looking for help in poking /
filling the holes. Who knows you may be looking for an example, so
here goes.....
Data Layer
Straight vs2005 generated typed datasets for all updatable data access.
For read only reporting and display data access we will use untyped
datasets. We have not had much success with data readers so we will
shy away from them if possible. You can generate a strongly typed
dataset so we won't bore you with the details.
Business layer
Accepts requests from pres layer or web service layer and interacts
with the data layer. Any necessary validation, conditional
enforcement, or other business logic is checked / applied. In many
cases this is just a pass through if we have done a good job with
required fields, getting and setting nulls for value types, and client
side validation. In others, especially calls from the web services,
there will be a bit of processing going on in the Biz obj. This layer
is not creating a business object from the typed dataset, only
interacting with the datasets as they pass through.
Presentation layer
Is "Aware" of the typed datasets, but has no idea where they come from,
and is limited to reading data from them and plugging data into them.
All data access must go through the biz layer, even if just a pass
through or simple lookup. The pages are smart enough to do most of the
required field checking and input validation, however any conditional
biz logic or other complex enforcement is left to the biz object. We
are currently storing the typed datasets in the viewstate. As
mentioned before the users all have reliable connectivity. We don't
load any data that we are not willing to put on the page so there are
no data security issues. All of our updatable datasets are dealing
with 1 or 2 rows data so they don't really bloat the viewstate all that
badly.
We have implemented several pages and so far it seems to be working.
The typed dataset is living up to the billing of reducing both design
and run time errors due to the increased use of intellisense. The
performance so far is great and we are already reaping the benefits of
reusable code blocks, both in the data and biz layers.
So there it is - shoot it down before it multiplies. We think we are
on the right track - but since we built the track - what else would
we think? I would be glad to provide some code samples upon request
Thanks in advance.