Data Layer architecture

  • Thread starter Thread starter laimis
  • Start date Start date
L

laimis

Hey guys,

I just recently got introduced to data mappers (DTO mapper). So now I
have a SqlHelper being used by DTOMapper and then business layer is
using DTOMapper when it needs to persist object to database or load them
back. Everything is working nicely so far. My question is, is it OK
practice to use DTOMapper rfom the presentation layer? For instance, if
I want to present in HTML format the list of entries in my database,
should I use DTOmapper from the presentation, or instead use Entries
collection method which internally uses DTOMapper.

THe second option sounds more cleaner and more seperated. Just want to
see what you guys think...

Thanks!

Laimis
 
Hi,

Of course the send option is the best. I thinkd the architecture should
looks like:

presentation layer
|
business logic layer
|
data access layer


Check MS's PetShop sample, you will get your idea clearer.
 
Edwin said:
Hi,

Of course the send option is the best. I thinkd the architecture
should looks like:

presentation layer
|
business logic layer
|
data access layer


Check MS's PetShop sample, you will get your idea clearer.
Click to expand...

If there's *ONE* sample which is badly constructed and horrible coded
it's the MS Petshop sample. It's solely developed to show how fast .NET
can be, not how to write an application in an n-tier fashion.

FB



--
 
There are a couple of ways of using Data Transfer Objects. By Mapper, do
you mean the Assembler pattern?

To see how to use the DTO concept in .Net, see:
http://msdn.microsoft.com/library/d.../en-us/dnpatterns/html/ImpDTOtypedDataSet.asp

For details on how to use typed datasets as a DTO, see
http://adoguy.com/content.aspx?id=samplechapter/chapter1
and
http://www.codeproject.com/dotnet/InheritFromDataSet.asp

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
 
After looking at the links provided by Nick (and enterprise patterns
book), I realized that I have misunderstood DTO pattern. What I really
needed is a mapper actually.

My desing now looks like this:

UI Layer:
aspx, user controls, pages, etc.

Business:
Various business objects

Data Layer:
DbMapper (is able to translate IDataReader or DataSet to business
object)
DbProvider (has sql code and procedures)
SqlHelper (and MsSqlHelper) for direct access to db

DbMapper is accessed through IDbMapper interface. It is loaded using
factory method which sets up the mapper with appropriate DbProvider.
DbProvider uses uses either SqlHelper or MsSqlHelper (depending on what
db is used) to access the db.

I will probably have seperate DbProviders for MsSql and MySql because
queries and some calls are different and then IDbMapper will be using
IDbProvider.

I would be very very thankful if someone with experience could comment
on my design. My main goal was to move the sql out of business objects
and isolate sql from actual translation of datasets or datareaders to
business objects.

Let me know what you think,

thanks,

Laimis


Data Layer:
 
your design looks quite solid.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
I would be very very thankful if someone with experience could comment
on my design. My main goal was to move the sql out of business objects
and isolate sql from actual translation of datasets or datareaders to
business objects.
Click to expand...
Before you introduce extra layers of complexity, read this:
http://grumpyoldprogrammer.myblogsite.com/blog/_archives/2005/5/13/851175.html

Looks like everyone (including me) has to learn that the hard way though.
:)

Greetings,
Wessel
 
Before you introduce extra layers of complexity, read this:
http://grumpyoldprogrammer.myblogsite.com/blog/_archives/2005/5/13/851175.html


Looks like everyone (including me) has to learn that the hard way
though. :)
Click to expand...

Well I think what this article and many other books, posts about
software design, all underline one key software design rule: consider
tradeoffs of your decisions.

And maybe to clarify, I am not thinking for every business layer class
to have a corresponding data layer class and other crazy stuff. Not at
all :) I just want that procedure or sql call out of my business
objects. It is ugly and adds of bunchy of ugle sql code or procedures
mixed up with business logic implemented in C#.
 
Please don't feed the trolls.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
 
Please don't feed the trolls.Thanks for that? Laimis put the spirit of the post right when he said
"consider tradeoffs of your decisions".

One of the projects I worked on failed because it had too many layers.
The design was all by the books (Microsoft's "Designing Component-Based
Applications" by Mary Kirtland.) It was hard work to develop.

When we finally had the first working version, the bugfixes and
requirement changes started to come in. For each requirement, we had to
change the database, data access, business logic, and presentation
layers. Then we had to write a converter for the database and all of the
messages in the queues. Then we had to write an installer to update the
application. We had made a wrong tradeoff for this particular project;
the time required for the extra layers wasn't worth it. The project was
cancelled.

On a next project, I used only two layers and dropped the message queues.
Development speed was amazing. We were responsive to the customer's
requests, and able to deliver on time.

A good learning experience though.

Greetings,
Wessel
 
One of the projects I worked on failed because it had too many layers.
The design was all by the books (Microsoft's "Designing Component-Based
Applications" by Mary Kirtland.)
Click to expand...

Very predictable. It is a suicide to follow trade media books written
by any programmer without a clue on formal data management theory.

The trade media publications lack almost any content quality control
and they are very endogamic. Any new nonsense written by a dare false
expert might be automatically propagated (regurgited) to many other
publications, and after a while it could be accepted as dogma by many
no brainer coders. This stuff happens everyday.
On a next project, I used only two layers and dropped the message queues.
Development speed was amazing. We were responsive to the customer's
requests, and able to deliver on time.

A good learning experience though.
Click to expand...

But it is a very expensive learning way. Everyone with a clue on data
management theory knows that the business logic must be ensured by the
DBMS and not by the applications (this is taught in the first week of
any serious database course).

Applications must be the presentation layer of an Information System
(something known since the 60's), and we should keep away from all the
business objects trade media garbage.

Congratulations for your blog.


Regards
 
Congratulations for your blog.Thanks for the compliment, but I could only wish to write a blog like
that. I'm just one of its readers.

Greetings,
Wessel
 
Alfredo said:
But it is a very expensive learning way. Everyone with a clue on data
management theory knows that the business logic must be ensured by the
DBMS and not by the applications (this is taught in the first week of
any serious database course).
Click to expand...

Hmm, then my serious db courses at the uni weren't very 'serious'
then!

NO law states that BL has to be IN the DBMS.

BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules. It only gives
context to the data its format it defines, no logic whatsoever.
Applications must be the presentation layer of an Information System
(something known since the 60's), and we should keep away from all the
business objects trade media garbage.
Click to expand...

One researcher once made a list of how many client-server
architectures there were, he came to 7 if I'm not mistaken. Your
proposed setup is one of them, but far from the only one.

What you suggest is typically a big-iron box in the basement, and thin
clients connecting to it, where all the software is written by DBA's.

I hope I don't have to drop the word 'scalability' on you.

FB

--
 
Hmm, then my serious db courses at the uni weren't very 'serious'
then!
Click to expand...
If they were anything like the ones I took, they were largely about theory
and in small part about simplified, idealistic practice.
BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules. It only gives
context to the data its format it defines, no logic whatsoever.
Click to expand...
I'd have to disagree with that. The relational model can enfore business
rules-- like, at most one customer per order, every order has a unique
identifier, and it's obligatory to fill in the postal code for an order.

Besides, there's more about a database than the relational model.
- It can restrict access for certain people (only managers can see other
people's salary; only senior help desk officers can re-assign tickets; ...)
- It can restrict status transitions by controlling the change through a
stored procedure (like moving an order from InProgress to Fullfilled;
requiring a resolve-date when a help desk ticket is closed; ...)
- It provides a fool-proof way to ensure there's only one version of the
business logic in production :)

Such safeguards in the database are simple to develop, and more fool-proof
than safeguards at another level. I think it's safe to say enforcing BL
in the database is a "best practice".
What you suggest is typically a big-iron box in the basement, and thin
clients connecting to it, where all the software is written by DBA's.

I hope I don't have to drop the word 'scalability' on you.
Click to expand...
Would you agree with the statement that in the vast majority of projects,
scalability is not an issue?

Greetings,
Wessel
 
Hmm, then my serious db courses at the uni weren't very 'serious'
then!
Click to expand...

If you don't know that I am afraid they were a little disaster.
Nothing rare, by the way.
NO law states that BL has to be IN the DBMS.
Click to expand...

No law, but it is a well stablished principle in the database
community. You might check the first chapter of any popular
introductory book like Date, Elmasri & Navathe, Korth & Silverschatz,
etc.
BL is a data-consuming tier, not part of the relational model. If you
pick up a book by Nijssen or Halpin, or Yourdon for that matter, you'll
learn that relational theory, e.g. the schema setup in your DBMS, is
not a theory which states anything about business rules.
Click to expand...

None of them is an expert on relational theory.

You should read Codd, Date or Fabian Pascal to get a clue. Business
rules support is one of the main components of any database model.

In a 1981 paper entitled "Data Models in Database Management" Codd
defined a data model to consist of a combination of three components:

1. A collection of data object types, which form the basic building
blocks for any database that conforms to the model;

2. A collection of general integrity rules (business rules), which
constraint the set of occurrences of those object types that can
legally appear in any such database;

3. A collection of operators, which can be applied to such object
occurrences for retrieval and other purposes

Source:

http://www.amazon.com/exec/obidos/tg/detail/-/0201612941?v=glance
It only gives
context to the data its format it defines, no logic whatsoever.
Click to expand...

The Relational Model is nothing but a direct application of set theory
and predicate logic to the data management field. If you don't know
that then you know practically nothing about it.

Codd's genial insigth was to use the mathematical logic for the
business logic. The Relational Model is a small branch of mathematical
logic.
One researcher once made a list of how many client-server
architectures there were, he came to 7 if I'm not mistaken. Your
proposed setup is one of them, but far from the only one.
Click to expand...

My proposed "setup" might have infinite architectural forms. Client
Server is only an special kind of distributed system. A distributed
DBMS composed by zillions of servers still is a single DBMS.
What you suggest is typically a big-iron box in the basement, and thin
clients connecting to it, where all the software is written by DBA's.
Click to expand...

All the business logic code is written by DBA's or database
programmers, but all presentation logic still needs to be written by
application programmers.
I hope I don't have to drop the word 'scalability' on you.
Click to expand...

Scalability has nothing to do with this. There are many ways to scale
a well designed Information System where all the business logic is
ensured by the DBMS.


Regards
 
I'd have to disagree with that. The relational model can enfore business
rules-- like, at most one customer per order, every order has a unique
identifier, and it's obligatory to fill in the postal code for an order.
Click to expand...

Any DBMS must be able to enforce any business rule. If not, it is not
a DBMS.

For instance MS Jet is not a DBMS, it is a primitive file processor.
Besides, there's more about a database than the relational model.
Click to expand...

Indeed. Besides what you said, the Relational Model says nothing about
the objects you store in the tuple attributes, but they must be
validated by the DBMS either.

Here is a very interesting interview:

http://www.dbmsmag.com/int9410.html
- It can restrict status transitions by controlling the change through a
stored procedure (like moving an order from InProgress to Fullfilled;
requiring a resolve-date when a help desk ticket is closed; ...)
Click to expand...

It could be done with a declarative constraint too.
- It provides a fool-proof way to ensure there's only one version of the
business logic in production :)
Click to expand...

Something essential.
Such safeguards in the database are simple to develop, and more fool-proof
than safeguards at another level. I think it's safe to say enforcing BL
in the database is a "best practice".
Click to expand...

It is the only sensible practice.


Regards
 
General integrity rules != business rules.
Click to expand...

General integrity rules are business rules.

Business rules are usually divided in constraint rules and derivation
rules, but any business rule might be considered as a constraint rule.

If we declare that an invoice total is the sum of all invoice line
subtotals, this is a derivation rule, but we are also constrainting
(to one) the possible values of the "Total" derived attribute.

On the other hand, structural business rules are clearly constraint
rules.

See this:

http://www.businessrulesgroup.org/brghome.htm
http://www.businessrulesgroup.org/brgdefn.htm
http://www.alphora.com/12Rules-Date.pdf


Regards
 
Alfredo Novoa said:
General integrity rules are business rules.
Click to expand...

They are arguably a subset of business rules. Personally, I prefer to
see them as an implementation specific requirement of a particular class
of structured storage, but then I consider databases a necessary and
largely unavoidable evil.
Business rules are usually divided in constraint rules and derivation
rules, but any business rule might be considered as a constraint rule.
Click to expand...

You're looking at this from a very data-centric point of view. This is
perfectly reasonable given that you approach system design from that
angle, but it isn't the only way of doing so.
 
Back
Top