Multilayer applications

[Just D]

Hi,

People, I'd like to get some statistics about who and how writes a
multilayer applications.

We're having at least a few layers:

1. Representation layer, i.e. GUI.
2. Business logic layer.

What else? A data layer working with database, datasets etc.? Does anybody
separates this layer of it's easier to combine the last one with the
business logic layer? What are PROs and CONTRAs?

Another one question - we can get the DataSet from the database, then parse
it into our custom objects and work with objects. But I like to work with
DataSets directly where I see that it brings me some advantage, for example
it's the most useful solution to show the data in a DataGrid or in a
DataTable then I get my own object and fill up the DataGrid manually.

Can anybody write just a few words how he works with Web Applications for
example, the structure of the project, etc.?

Does anybody save the SQL queries into a separate file and makes a separate
data layer just to work with the database? Or basically all are preferring
to work at the business logic layer?

Thanks,
Dmitri

 

[SP]

Hi,

People, I'd like to get some statistics about who and how writes a
multilayer applications.

We're having at least a few layers:

1. Representation layer, i.e. GUI.
2. Business logic layer.

What else? A data layer working with database, datasets etc.? Does anybody
separates this layer of it's easier to combine the last one with the
business logic layer? What are PROs and CONTRAs?

I generally separate it and reference it from the business layer. This keeps
you from being able to make the direct database calls from your GUI.

Another one question - we can get the DataSet from the database, then parse
it into our custom objects and work with objects. But I like to work with
DataSets directly where I see that it brings me some advantage, for example
it's the most useful solution to show the data in a DataGrid or in a
DataTable then I get my own object and fill up the DataGrid manually.

Stick with your custom objects and use datareaders. In time you will become
frustrated with the limitations of datasets in most situations.

Can anybody write just a few words how he works with Web Applications for
example, the structure of the project, etc.?

Not sure what you want here. A few pointers on web apps in general. Keep the
GUI simple. Try not to make a "Windows" app in your browser. Avoid view
state and session state as much as possible. Use hidden variables or
parameters as your WinForms equivalent of "static" variables.

Does anybody save the SQL queries into a separate file and makes a separate
data layer just to work with the database? Or basically all are preferring
to work at the business logic layer?

Yes. My personal favorite is to use code generation to create all the
database methods (using SQLXML and XSLT). You end up with methods like
IDataReader MySelectStoredProcedure(int parameter1, string parameter2)
{
// the code that returns a datareader
}

created automatically for every stored procedure.

SP

 

[Just D]

Hi,

Thanks for the answer.

I generally separate it and reference it from the business layer. This
keeps
you from being able to make the direct database calls from your GUI.

I supposed that GUI and the busuness logic layer are different instances.
Yes, that makes sense to separate them but how much it should be done. I saw
later in this message that you prefer to use the stored procedures instead
of embedded text queries. Is it true? I use Sql Queries from my business
layer but I wrote a SqlWrapper class library and I just send these queries
there and get the DataSets back.

Stick with your custom objects and use datareaders. In time you will
become
frustrated with the limitations of datasets in most situations.

Hm, if I need just to get some data and show it on the DataGrid then why
should I use my own custom object instead of a DataSet, it's easier to bind
an existing object to the DataGrid and enjoy. Am I right or not? Or you
parse all DataSets and create your own custom class then expose it? In all
other cases it's more convenient to use my own classes to work with data, I
know that.

Keep the GUI simple. Try not to make a "Windows" app in your browser.
Avoid view
state and session state as much as possible. Use hidden variables or

It's not always easy to go this way. Sometimes I use the same page to show
something and to edit something. It's my boss requirement. That's why I need
the page status, just to switch between page modes and it works fine.

parameters as your WinForms equivalent of "static" variables.

Yes, I found this trick, but sometimes these hidden variables are visible if
you save the page from your browser and that's not good. I saw many examples
when I was trying to save some page just to remember about the transaction
and I was getting a whole bunch of variables, hidden in a usual mode, but
visible in saved mode. That's funny, but not critical.

Yes. My personal favorite is to use code generation to create all the
database methods (using SQLXML and XSLT). You end up with methods like

Do you always use the Stored Procedures and never an implemented SQL code?

IDataReader MySelectStoredProcedure(int parameter1, string parameter2)
{
// the code that returns a datareader
}
created automatically for every stored procedure.

I saw one solution where all SQL queries have been stored into external XML
file. I don't see that this approach is very good but it exists. From my
point of view it's much better to use a business layer to work with queries.
Maybe I'm wrong.

The main reason why I don't like this way - I can't use these class
libraries from Windows Application, because all these queries will be shared
as a simple text file. There is no security at all.

So how many layers you use?

1. GUI.
2. Business logic layer.
3. Database access layer.

Correct?

Are you having all your queries stored on the database as SPs?

Thanks,
Dmitri

 

[Nick Malik]

My two bits:

there is a difference between a layer on one machine and creating
independent objects on multiple networked systems. I'm refraining my
comments to the idea of a layer of classes, all implemented in a single
solution, and deployed to a single machine. I can discuss the other, but
that doesn't appear to be the topic in question.

I usually have a low level data object of some kind, just to isolate my code
from the calls to ADO.NET... mostly because I don't trust that the ADO
interface itself won't change. I add on other classes to form the data
layer. The logic for connecting to the database, and the logic for getting
the data into the right entities, is all handled in the data layer objects
(which may be quite a few classes).

The business objects layer does not know the following:
--- whether data is accessed using SQL statements or stored proces
--- the names of the stored procedures, or the names of the tables
themselves.
--- when to create a transaction and when to commit it
--- where to get the connection string, and what to do if the login fails
--- how to manage the connection object, or whether the database is
connected
--- what version of MDAC is installed
--- what foreign key column has to be copied to a dependent table row
when it is created
--- whether primary key values are mnemonic, auto-number, or
uniqueidentifier (GUID), and who assigns them.

It is OK if the business layer knows the following...
--- that data is stored in tables, as long as the BL doesn't need to refer
to the actual table names
--- that the data is stored in a SQL Server RDBMS (that's pretty specific,
but I'm willing to live with it)
--- the names and data types of the columns
--- the values for the Primary Keys

Other people may want to partition these responsibilities differently, and
I'm not saying that this list, which usually works for me, will work for
anyone else, or even that it always works for me in every possible case.
That depends on the application.

I have some other rules of thumb:
--- write no code that obscures good functionality already provided in
the framework Extension is OK. Hiding for the sake of hiding is harmful.
--- I will write a defect for every 20 lines of code (on a really good
day). If I don't want to create job security, I will write as little code
as possible.
--- Use design patterns to hide the details of implementing an object, so
that objects that have the same
attributes can be substituted for each other (my loose
interpretation of the Liskov Substitution Principle)
--- Minimize Coupling. Maximize Cohesion. Harder to do than it sounds.

Personally, I have no problem passing around data in DataSet objects. I
personally have not become disenchanted with them, but I don't pretend to
use every feature. If I did, I imagine I would join the chorus of folks who
can find fault with this generic disconnected data object. I also have no
problem using a DataReader, and copying the data into a collection of
DataRow objects that I pass around.

The U/I layer is more than the ASP.NET web pages. I use code behinds
exclusively. In addition, there is nearly no code in the code behind. Only
enough to create an object that is used by the page and to call that object.
This layer of U/I objects is still part of the U/I layer. This is done so
that I can write NUnit tests for the U/I objects without having to call the
Web pages themselves to test the application.
My rules of thumb for the U/I management layer:
--- no web or windows controls may be passed as a parameter to the U/I
object layer.
--- validation happens in the U/I management layer by calling the
business object layer. It does not happen in the
code behind and, as much as possible, it does not happen in the U/I
management code itself... it's a pass through.
--- If I must hard-code a list of values for the web pages, the list is
specified in an object in the U/I management layer, not in the web page.
--- Use the O/S to provide security services as much as possible. Do not
store passwords in the database, due to the
complexities of handling encrypted in a secure manner. (This also
goes back to writing as little code as I can).

Business rules live in the BL. The rules do, and the formulas do.
Constants, however, and easily isolated hard-coded strings, all live in the
config files. Note: all layers can use the config files. There is nothing
at all wrong with placing the names of your stored procedures in the config
files as well as the business rule constants. (For example, if I have a
rule that says "when an invoice goes unpaid for 30 days, send a message to
the exchange alias "WarnAccounting", then I will store the number 30 and the
alias "WarnAccounting" in the config file, along with the name of an XSL
template that will be used to generate the layout of the e-mail itself).

I hope this helps.

--- Nick Malik

 

[SP]

Hm, if I need just to get some data and show it on the DataGrid then why
should I use my own custom object instead of a DataSet, it's easier to bind
an existing object to the DataGrid and enjoy. Am I right or not? Or you
parse all DataSets and create your own custom class then expose it? In all
other cases it's more convenient to use my own classes to work with data, I
know that.

This forces you to make sure the actual data is present in the dataset. Your
business object is not constrained in needing to contain
the actual "display" data, e.g Your Employee object has a EmployeeName and
DepartmentName properties. But
internally the Employee object only knows the Department key and is really
calling DepartmentsCollection[key].DepartmentName to provide the
"display" data. Getting the same behavior from a dataset is not so easy. I
like the ability to make my business objects "self serving".

It's not always easy to go this way. Sometimes I use the same page to show
something and to edit something. It's my boss requirement. That's why I need
the page status, just to switch between page modes and it works fine.

Any "sophisticated" control will need ViewState in order to provide the
events necessary to handle multiple edits etc.
But selecting an employee from a dropdown list of 1000 employees can be
handled with some javascript and a hidden field.

Do you always use the Stored Procedures and never an implemented SQL code?

Unless I need to provide custom querying then stored procedures cover all
the bases. A data mapper co-ordinates between the business
classes and the database layer. It is "add new, delete removed, update
dirty".

I saw one solution where all SQL queries have been stored into external XML
file. I don't see that this approach is very good but it exists. From my
point of view it's much better to use a business layer to work with queries.
The main reason why I don't like this way - I can't use these class
libraries from Windows Application, because all these queries will be shared
as a simple text file. There is no security at all.

My method does not distribute the XML file. It uses this metadata to
generate a database class and business object abstract classes.
I change the XSLT around to suit the methods I want for the particular
project. Sometimes I pass the business object to the
stored procedure method and let it get the values it needs from the object
rather than populating a long list of
parameters.

SP

 

[Nick Malik]

Hi SP,

Your XSLT data layer generater sounds very interesting.
Where can I find out more? Did you buy it? Download it?

If you wrote it, could you put an article on codeproject?

It sounds pretty cool.

--- Nick

Hm, if I need just to get some data and show it on the DataGrid then why
should I use my own custom object instead of a DataSet, it's easier to bind
an existing object to the DataGrid and enjoy. Am I right or not? Or you
parse all DataSets and create your own custom class then expose it? In all
other cases it's more convenient to use my own classes to work with

data,

I
know that.

This forces you to make sure the actual data is present in the dataset. Your
business object is not constrained in needing to contain
the actual "display" data, e.g Your Employee object has a EmployeeName and
DepartmentName properties. But
internally the Employee object only knows the Department key and is really
calling DepartmentsCollection[key].DepartmentName to provide the
"display" data. Getting the same behavior from a dataset is not so easy. I
like the ability to make my business objects "self serving".

It's not always easy to go this way. Sometimes I use the same page to show
something and to edit something. It's my boss requirement. That's why I need
the page status, just to switch between page modes and it works fine.

Any "sophisticated" control will need ViewState in order to provide the
events necessary to handle multiple edits etc.
But selecting an employee from a dropdown list of 1000 employees can be
handled with some javascript and a hidden field.

Do you always use the Stored Procedures and never an implemented SQL

code?

Unless I need to provide custom querying then stored procedures cover all
the bases. A data mapper co-ordinates between the business
classes and the database layer. It is "add new, delete removed, update
dirty".

I saw one solution where all SQL queries have been stored into external XML
file. I don't see that this approach is very good but it exists. From my
point of view it's much better to use a business layer to work with queries.
The main reason why I don't like this way - I can't use these class
libraries from Windows Application, because all these queries will be shared
as a simple text file. There is no security at all.

My method does not distribute the XML file. It uses this metadata to
generate a database class and business object abstract classes.
I change the XSLT around to suit the methods I want for the particular
project. Sometimes I pass the business object to the
stored procedure method and let it get the values it needs from the object
rather than populating a long list of
parameters.

SP

 

[Just D]

Hi,

This forces you to make sure the actual data is present in the dataset.
Your

That's only one call to your SqlWrapper like:

public bool IsDataSetOK(DataSet ds)
{
return ((ds!=null)&&(ds.Tables.Count>0)&&(ds.Tables[0].Rows.Count>0));
}

business object is not constrained in needing to contain
the actual "display" data, e.g Your Employee object has a EmployeeName and

Not exactly, it depends what data do you need at this moment, but you easily
can add a column manually and add some calculated data to this column.

DepartmentName properties. But
internally the Employee object only knows the Department key and is really
calling DepartmentsCollection[key].DepartmentName to provide the
"display" data. Getting the same behavior from a dataset is not so easy. I
like the ability to make my business objects "self serving".

Not so easy?! Why? What about sql queries (and maybe subqueries) providing a
comprehensive information? You can join on this DepartmentKey a few tables
getting all required stuff into additional DataSet column and reflect this
column in the DataGrid automatically just from one database call, it's
easier than retrieve the whole information in two or more datasets, then
make a foreach loop every one when you need to compare two or more tables.
In a SQL solution everyting should be solved by SQL engine itself.

But selecting an employee from a dropdown list of 1000 employees can be
handled with some javascript and a hidden field.

Yes, but these is only one solution, You can use LIKE '%!@!#!@#%' in your
queries to get only required records by mask, you can sort them by the
alphabet and return only required group, there are many different methods.
You also can use browse feature of SQL queries, etc.

My method does not distribute the XML file. It uses this metadata to
generate a database class and business object abstract classes.
I change the XSLT around to suit the methods I want for the particular
project. Sometimes I pass the business object to the
stored procedure method and let it get the values it needs from the object
rather than populating a long list of parameters.

That's interesting.

Thanks,
Dmitri

 

[SP]

Hi SP,

Your XSLT data layer generater sounds very interesting.
Where can I find out more? Did you buy it? Download it?

If you wrote it, could you put an article on codeproject?

It sounds pretty cool.

The basis of it was from an article in msdn magazine August 2003.
http://msdn.microsoft.com/msdnmag/issues/03/08/CodeGeneration/default.aspx
I tweaked the query that generated the XML metadata and I enhance the XSLT
file
on a per project basis. It eliminate a lot of repetitive data access layer
coding and
immediately reflects any added or changed stored procedures.

 

[SP]

and

Not exactly, it depends what data do you need at this moment, but you easily
can add a column manually and add some calculated data to this column.

Exactly my point, you need to handle that particular situation "manually". I
prefer "automatic".

DepartmentName properties. But
internally the Employee object only knows the Department key and is really
calling DepartmentsCollection[key].DepartmentName to provide the
"display" data. Getting the same behavior from a dataset is not so easy. I
like the ability to make my business objects "self serving".

Not so easy?! Why? What about sql queries (and maybe subqueries) providing a
comprehensive information? You can join on this DepartmentKey a few tables
getting all required stuff into additional DataSet column and reflect this
column in the DataGrid automatically just from one database call, it's
easier than retrieve the whole information in two or more datasets, then
make a foreach loop every one when you need to compare two or more tables.
In a SQL solution everyting should be solved by SQL engine itself.

I tend to disagree with this. At a certain point the complexity of what you
are doing in the
SQL engine increases and crosses into the business rules.

In the example I gave you would have a grid with the EmployeeName and their
Department.
If I want to be able to change the department using a dropdown, how easy is
that to implement using your datasets.
Once you use a join to create a dataset you can not use the dataadapter to
persist the
changes made in that dataset directly back to the database. This was the one
thing that was most frustrating
about datasets.

Yes, but these is only one solution, You can use LIKE '%!@!#!@#%' in your
queries to get only required records by mask, you can sort them by the
alphabet and return only required group, there are many different methods.
You also can use browse feature of SQL queries, etc.

I was refering to this as something that can be handled "quickly" by using
viewstate on the
dropdown which will slow down the page and the postback, or can be handled
with
a hidden field and javascript and will make a much faster loading webpage.

SP

 

[Just D]

Hi,

I tend to disagree with this. At a certain point the complexity of what
you
are doing in the SQL engine increases and crosses into the business rules.

Ok, what are your rules? Do you just get as simple data as possible and do
the rest on the code? But why the whole world is still using the joins,
table relations etc.? What are advs./disadvs. of both solutions?

If I want to be able to change the department using a dropdown, how easy
is
that to implement using your datasets.
Once you use a join to create a dataset you can not use the dataadapter to
persist the
changes made in that dataset directly back to the database. This was the
one
thing that was most frustrating
about datasets.

Stop, are you allowing all changes made in the same DataGrid? I usually make
a separate dialog to make these changes. I don't ask about disadvantages,
I'm just wondering...

Thanks,
Dmitri

 

[SP]

Hi,
rules.

Ok, what are your rules? Do you just get as simple data as possible and do
the rest on the code? But why the whole world is still using the joins,
table relations etc.? What are advs./disadvs. of both solutions?

If the complexity of the data requires joins then I would still have an
object to represent this.
I just wouldn't join to get data that I am already handling with another
object.
E.g. Boss wants employees with total sales for the year. Let's say we have
the employee object
already handled and now want to "add" total sales to the grid we were
displaying.
We populate a collection of total sales objects - employee key and total
from a stored procedure.
It might involve any number of tables joined together but returns just
employee key
and total sales.
From our employee object we can do
Employee.TotalSales which is really doing
TotalSalesCollection[employeeKey].TotalSales

The boss likes this and now wants to see the employees supervisor and their
sales so
we add these properties to the datagrid columns
Employee.Supervisor.EmployeeName
Employee.Supervisor.TotalSales

I guess what I like is we had our Employee object and we had our Supervisor
property.
When we added the TotalSales property we got the Supervisor.TotalSales for
"free",
i.e. no additional coding.

As your project evolves you get more of these bonuses without additional
coding.
E.g. Average sales per employee in the employees department including the
Supervisor (who is in a different department)
(Employee.Department.TotalSales + Employee.Supervisor.TotalSales) /
(Employee.Department.Count + 1 //supervisor)

Regards,

SP

 

[Nick Malik]

What rules do you follow to figure out how you will partition the logic in
your data layer.

It sounds to me like you are hiding a lot more than data representation in
the data layer.

--- Nick

Hi,
rules.

Ok, what are your rules? Do you just get as simple data as possible and do
the rest on the code? But why the whole world is still using the joins,
table relations etc.? What are advs./disadvs. of both solutions?

If the complexity of the data requires joins then I would still have an
object to represent this.
I just wouldn't join to get data that I am already handling with another
object.
E.g. Boss wants employees with total sales for the year. Let's say we have
the employee object
already handled and now want to "add" total sales to the grid we were
displaying.
We populate a collection of total sales objects - employee key and total
from a stored procedure.
It might involve any number of tables joined together but returns just
employee key
and total sales.
From our employee object we can do
Employee.TotalSales which is really doing
TotalSalesCollection[employeeKey].TotalSales

The boss likes this and now wants to see the employees supervisor and their
sales so
we add these properties to the datagrid columns
Employee.Supervisor.EmployeeName
Employee.Supervisor.TotalSales

I guess what I like is we had our Employee object and we had our Supervisor
property.
When we added the TotalSales property we got the Supervisor.TotalSales for
"free",
i.e. no additional coding.

As your project evolves you get more of these bonuses without additional
coding.
E.g. Average sales per employee in the employees department including the
Supervisor (who is in a different department)
(Employee.Department.TotalSales + Employee.Supervisor.TotalSales) /
(Employee.Department.Count + 1 //supervisor)

Regards,

SP

 

[Just D]

Hi Nick,

It sounds to me like you are hiding a lot more than data representation in
the data layer.

You know, I'm just asking the whole community what methods people are using?
As I see the MS definition - the GUI (ASPX) and codebehind (ASPX.CS) files
help us to divide the GUI and the business logic. From the other side when
we work with the database we need a set of classes to hold and manipulate
our data- i.e. class library for our objects and (maybe) another lower level
layer to work with the database and our queries. So what should be the
general structure using by people to write WebApps?

1. GUI (ASPX)
2. Codebehind (ASPX.CS)
3. Class Library, business logic, etc.
4. Low-level database access, DataAdapters, queries, etc.

Questions are:

Can we join 3 and 4, does it bring simplicity or it's always better to have
them separate, especially in big projects?

How can we handle the queries, as Stored Procedures, as strings in some
resource file etc., especially keeping in mind that the same class libraries
could be helpful for the Windows Applications and we should avoid any
sharing of SQL queries in text files or even in resource files. It's easily
accessible and readable, even changeable.

Can we use DataSet instead of customized classes filled from DataSets just
to show the data in DataGrids or it's always better to use a custom class
and Bind it to the DataGrid? I have some ideas about it but mostly people
are saying that it's better to use a custom class instead of a DataSet.
That's strange because the old-fashioned approach was - Bind the DataSet and
just add a couple methods to Update/Insert, maybe Delete and everything will
be done itself. I see that the work with custom classes brings much more
efforts and machine time, especially if we parse data from the DataSet
filling the custom object.

That's why I raised up this thread, just to know what people are thinking
about it.

Thanks,
Dmitri

 

[Nick Malik]

I answered your question in the following blog entry:
http://biztalkbum.blogspot.com/2004/07/how-i-go-about-partitioning-logic-into.html

I hope this helps.
--- Nick

 

[SP]

What rules do you follow to figure out how you will partition the logic in
your data layer.

It sounds to me like you are hiding a lot more than data representation in
the data layer.

The objects discussed were business objects in the business layer.

SP

and

do

the rest on the code? But why the whole world is still using the joins,
table relations etc.? What are advs./disadvs. of both solutions?

If the complexity of the data requires joins then I would still have an
object to represent this.
I just wouldn't join to get data that I am already handling with another
object.
E.g. Boss wants employees with total sales for the year. Let's say we have
the employee object
already handled and now want to "add" total sales to the grid we were
displaying.
We populate a collection of total sales objects - employee key and total
from a stored procedure.
It might involve any number of tables joined together but returns just
employee key
and total sales.
From our employee object we can do
Employee.TotalSales which is really doing
TotalSalesCollection[employeeKey].TotalSales

The boss likes this and now wants to see the employees supervisor and their
sales so
we add these properties to the datagrid columns
Employee.Supervisor.EmployeeName
Employee.Supervisor.TotalSales

I guess what I like is we had our Employee object and we had our Supervisor
property.
When we added the TotalSales property we got the Supervisor.TotalSales for
"free",
i.e. no additional coding.

As your project evolves you get more of these bonuses without additional
coding.
E.g. Average sales per employee in the employees department including the
Supervisor (who is in a different department)
(Employee.Department.TotalSales + Employee.Supervisor.TotalSales) /
(Employee.Department.Count + 1 //supervisor)

 

[Nick Malik]

Hi SP.

The objects discussed were business objects in the business layer.

I know. I asked about the rules you follow to decide what functionality
should go in the business layer and what should go in the data layer. If
you follow purely technical rules (I code, therefore I am) then you may veer
off into writing cool functions into the data layer that do not have any
ultimate benefit to your code. I may be mistaken, but it looks strongly
like you have done precisely that, and then enshrined these "features" in
automatically generated code.

Ever heard of the acronym: YAGNI?
It means "You Ain't Gonna Need It."
It's a term in Agile Programming circles.

It means: don't add functionality that you don't have either a direct
request for (from the customer) or you haven't refactored in to improve code
structure.

This reduces the tendency of developers to "gold-plate" their code by adding
features that are cool but totally unnecessary.

I'm concerned that I asked you for your partitioning rules and you answered
with a null response. Does that mean that you don't have a set of
partitioning rules that you follow? Is that (a) intentional, or (b)
unintentional? If (a), that's bad. If (b), that's worse. On the other
hand, you may have rules that you follow, and I'm being unfair.

The OP was asking for your partitioning rules. I posted mine in a prior
response and then made a blog entry based on it.
http://biztalkbum.blogspot.com/2004/07/how-i-go-about-partitioning-logic-into.html

Please post yours.

--- Nick

 

[SP]

The objects discussed were business objects in the business layer.

I know. I asked about the rules you follow to decide what functionality
should go in the business layer and what should go in the data layer. If
you follow purely technical rules (I code, therefore I am) then you may veer
off into writing cool functions into the data layer that do not have any
ultimate benefit to your code. I may be mistaken, but it looks strongly
like you have done precisely that, and then enshrined these "features" in
automatically generated code.

Ever heard of the acronym: YAGNI?
It means "You Ain't Gonna Need It."
It's a term in Agile Programming circles.

It means: don't add functionality that you don't have either a direct
request for (from the customer) or you haven't refactored in to improve code
structure.

This reduces the tendency of developers to "gold-plate" their code by adding
features that are cool but totally unnecessary.

I'm concerned that I asked you for your partitioning rules and you answered
with a null response. Does that mean that you don't have a set of
partitioning rules that you follow? Is that (a) intentional, or (b)
unintentional? If (a), that's bad. If (b), that's worse. On the other
hand, you may have rules that you follow, and I'm being unfair.

The OP was asking for your partitioning rules. I posted mine in a prior
response and then made a blog entry based on it.

http://biztalkbum.blogspot.com/2004/07/how-i-go-about-partitioning-logic-into.html

I appreciate your concern!! My data access layer is pretty standard. A
wrapper for stored procedures,
database connections, transaction handling. The only non-standard thing
(perhaps) is that I have overloaded
Update, Delete and Insert methods that have the interface of the business
objects as the only parameter. It allows the unit of work object to
call the Update/Insert/Delete methods in the business objects that that in
turn call Database.getInstance().Update(this) /Delete(this),/Insert(this).
You could
say that I have some of my data mapping code in my data layer, e.g.
MyObject.MyProperty will be used for the value of the parameter
called MyProperty. MyObject.MyProperty will exist because the table
structure was turned into a abstract class
that is inherited by the business objects. Now because of the abstract
classes I do have properties in my business objects
where the setters translate to the database key

public User User
{
get
{
return Users[base.FkUserID];
}
set
{
base .FkUserID = value.PkUserID
}
}

You could say I am doing my data mapping in with my business objects which
you may not agree with.
Perhaps I should be storing the object reference then getting the key in the
data mapper.

Let me know if I missed out anything.

SP