N
Natehop
I've been attempting to design an n-tiered framework leveraging .NET's
strongly typed Dataset. My Framework will serve as the foundation to
several client apps from Windows applications to web sites and web
services.
The architecture consists of a business rules tier, a data tier, and a
common tier. The common tier contains my typed Datasets while the
business rules and data tiers contain functions to populate and save the
common Datasets. Pretty standard n-tier design; however, I'm having
quite the time determining what database tables my typed Datasets should
contain.
I've read several articles, books, and newsgroups in an attempt to find
some best practices regarding this issue; however, my inquiries thus far
illustrate that no best practices have yet evolved.
My research and experience has led me to 2 possible solutions.
--PROBLEM DOMAINS -----------------------------------
The first solution is to use "problem domains" when designing the Dataset
schema. The key to problem domains is that they encapsulate all needed
tables within the Dataset. The issue I find with this approach is that
it requires one to make a judgment early in the development lifecycle as
to what problem domains exist and what tables fall within them, leaving a
high probability for mistakes and either missing tables that should have
been included or including tables that really weren't needed. The
probability of getting it wrong increasing with the size and complexity
of your database. Not to mention any unknown requirements that will be
placed on the framework 6 months from now. The other issue I find with
problem domains is that they are driven by features. This means that its
highly likely that a problem domain could exist for every feature in the
application. No code reuse, and the framework simply becomes unneeded
complexity.
--BUILDING BLOCKS------------------------------------
The second solution is to use a very granular approach when defining the
Dataset schema; meaning, we only include a parent table and all of its
children 1 level deep in the Dataset. I have spent the most time
experimenting with this solution, and while it addresses the issues posed
by problem domains, this solution has its shortcomings as well.
The first issue is the sheer number of objects required. Basically any
table that is a parent table becomes an object (typed Dataset). The
second issue that has met with resistance on my team is that management
of these objects is now pushed to the client. The client code may need
to create 2 or 3 of these granular objects for a given feature or
"problem domain". Which illustrates another issue... transactions. If
client code is working with 3 of these granular objects and needs to
update the database, how do I wrap the update of all 3 objects within a
single transaction if the data layer treats these objects as separate and
distinct (each have individual save methods within the data layer)?
One though I had was to make the data objects very granular and then wrap
them within a problem domain object at the business rules layer. That
way we end up with a very flexible and reusable data layer and common
layer. If we happen to be short sited when designing the business rules
objects or "problem domains", the impact will be much less on framework
development.
To over simplify, I'll use the object of a car.
If we are making Volkswagen Beetles, the problem domain solution is to
define the domain around that specific vehicle. When a new vehicle is
required, we create an entirely new vehicle. No reuse, but we get
everything we need in one object which is easily managed in the business
rule layer or data layer.
The granular approach is to first define the wheels, engine, seats,
etc... And then let either the client code or business rule layer build
the needed car with the components.
Obviously you can tell that I am leaning toward a more granular approach;
however, I was hoping to hear from someone who may be using either
technique or even something else with success.
Thanks in advance for any feedback and/or advice. Keep in mind that what
I'm really after is best practices.
-- Nate
-----------------------------------------------------------
"...touch a solemn truth in collision with a dogma...
though capable of the clearest proof, and you will find
you have disturbed a nest, and the hornets will swarm
about your eyes and hand, and fly into your face and eyes."
------------------------------------------------ John Adams
strongly typed Dataset. My Framework will serve as the foundation to
several client apps from Windows applications to web sites and web
services.
The architecture consists of a business rules tier, a data tier, and a
common tier. The common tier contains my typed Datasets while the
business rules and data tiers contain functions to populate and save the
common Datasets. Pretty standard n-tier design; however, I'm having
quite the time determining what database tables my typed Datasets should
contain.
I've read several articles, books, and newsgroups in an attempt to find
some best practices regarding this issue; however, my inquiries thus far
illustrate that no best practices have yet evolved.
My research and experience has led me to 2 possible solutions.
--PROBLEM DOMAINS -----------------------------------
The first solution is to use "problem domains" when designing the Dataset
schema. The key to problem domains is that they encapsulate all needed
tables within the Dataset. The issue I find with this approach is that
it requires one to make a judgment early in the development lifecycle as
to what problem domains exist and what tables fall within them, leaving a
high probability for mistakes and either missing tables that should have
been included or including tables that really weren't needed. The
probability of getting it wrong increasing with the size and complexity
of your database. Not to mention any unknown requirements that will be
placed on the framework 6 months from now. The other issue I find with
problem domains is that they are driven by features. This means that its
highly likely that a problem domain could exist for every feature in the
application. No code reuse, and the framework simply becomes unneeded
complexity.
--BUILDING BLOCKS------------------------------------
The second solution is to use a very granular approach when defining the
Dataset schema; meaning, we only include a parent table and all of its
children 1 level deep in the Dataset. I have spent the most time
experimenting with this solution, and while it addresses the issues posed
by problem domains, this solution has its shortcomings as well.
The first issue is the sheer number of objects required. Basically any
table that is a parent table becomes an object (typed Dataset). The
second issue that has met with resistance on my team is that management
of these objects is now pushed to the client. The client code may need
to create 2 or 3 of these granular objects for a given feature or
"problem domain". Which illustrates another issue... transactions. If
client code is working with 3 of these granular objects and needs to
update the database, how do I wrap the update of all 3 objects within a
single transaction if the data layer treats these objects as separate and
distinct (each have individual save methods within the data layer)?
One though I had was to make the data objects very granular and then wrap
them within a problem domain object at the business rules layer. That
way we end up with a very flexible and reusable data layer and common
layer. If we happen to be short sited when designing the business rules
objects or "problem domains", the impact will be much less on framework
development.
To over simplify, I'll use the object of a car.
If we are making Volkswagen Beetles, the problem domain solution is to
define the domain around that specific vehicle. When a new vehicle is
required, we create an entirely new vehicle. No reuse, but we get
everything we need in one object which is easily managed in the business
rule layer or data layer.
The granular approach is to first define the wheels, engine, seats,
etc... And then let either the client code or business rule layer build
the needed car with the components.
Obviously you can tell that I am leaning toward a more granular approach;
however, I was hoping to hear from someone who may be using either
technique or even something else with success.
Thanks in advance for any feedback and/or advice. Keep in mind that what
I'm really after is best practices.
-- Nate
-----------------------------------------------------------
"...touch a solemn truth in collision with a dogma...
though capable of the clearest proof, and you will find
you have disturbed a nest, and the hornets will swarm
about your eyes and hand, and fly into your face and eyes."
------------------------------------------------ John Adams
)