Hi JCC,
Excellent question!
Abstraction is a wonderful thing. But I don't think you understand it very
well. For example, you say that you have a "presentation layer which is an
aspnet application." This is simply not true. The application is the sum
total of the entire mess. The presentation layer is a user interface. A user
interface is the set of "stuff" that the user sees and interacts with. It is
composed of HTML entirely (unless you are using client-side executables,
etc). On the server side, it should be composed of ONLY those programming
entities that create the HTML. This includes Controls and their event
handlers. And that's pretty much it. Speaking abstractly, it is the part of
the app that presents information to the user. It is a "universal
translator" that speaks computer at one end, and human at the other. It is
like the car's dashboard and pedals.
The "business layer" is the "engine" of the application. It is composed of
business objects that work with data. It has no idea where the data comes
from. It only knows what it is, and how to manipulate it. It is like the
car's engine. The engine takes input from the driver, such as how hard he is
pushing on the gas pedal, how far he has turned the steering wheel in what
direction, etc, and makes the car do what the driver wants it to.
The data layer is what supplies the data to the business layer. It knows
nothing about the data. It only knows how to get it, and how to put it back.
It is like the gas tank on the car. The engine doesn't know where the fuel
is coming from. It only knows how to use it. The gas tank knows nothing
about making the car move. It only supplies fuel to a consumer (the engine).
And the presentation layer knows nothing about either of the other 2, only
how to send and receive messages to and from the human driving the car.
What I'm getting at is, if you think abstractly about these objects when
designing your app, they will make themselves intuitive to you. IOW, the
time to think about all the "stuff" that makes up the interface, engine, and
data layer is not during the design phase. It's best to think of them in
abstract terms, as things, not as code. You think of them as code when you
have to write it. So, when you plan your app, you should probably start with
the data layer, and work your way up to the interface. When you think of
each layer, think of what it should do, not how it should do it. Start from
the mil-high viewpoint, thinking in broad terms, and work your way down to
the details, which should become clearer as you move downward.
What should a data layer do? It should fetch data, store data, change data,
and delete data. How it does this is beyond the scope of what we're
discussing right now. We don't want to think about the details yet. What we
should keep in mind is that, when developing it, we should be on the lookout
for anything that doesn't fall into ne of the above categories, and find its
real home.
What should the business layer do? It should get data from somewhere, know
what the data is, and how to munge it, manipulate it, etc., and be able to
provide the data to an interface of some sort. it should also be able to
talk to the data layer and send it data that needs to be stored or updated,
as well as telling it to delete data. When we develop the business layer we
should be on the lookout for things which should NOT be in there, such as
talking to a database, or using any kind of interface Control.
What should the presentation layer do? It should be able to get data from
somewhere, make it look palatable to a human, and be able to send messages
from the user to the business layer, and from the business layer to the
user. It should never attempt to munge or manipulate data.
--
HTH,
Kevin Spencer
Microsoft MVP
..Net Developer
Sometimes you eat the elephant.
Sometimes the elephant eats you.
"Guest" <Guest@aew_nospam.com> wrote in message
news:uX**************@TK2MSFTNGP15.phx.gbl...
I'd appreciate some help from any architectural gurus out there. I'm
creating a web app with 3 tiers,
A presentation layer which is an aspnet application.
A business object layer which is a group of custom classes that map to my
database entities, items of each type, for example 'clientitem' and
collection classes that are collections of items, for example
'clientcollection'.
A data access layer that uses a component class connected to a sql database
and uses commands, adapters and datasets to return my data to the business
object layer.
I've referenced the bol in my aspnet app and get some quite useful
abstraction from the database using this method, my aspnet app is completely
ignorant of any information regarding the database, field names, anything
really.
I've referenced my dal app in my bol app and what I am finding is that I am
now required to tie the business object layer to the database layer, field
names etc, I could use field position numbers/ordingals but I find this
unreliable, confusing and possibly troublesome, I don't want to tie my bol
to my dal, how can I avoid this? Or am I just dreaming, I realise the rubber
has got to touch the road somewhere, the only thing I can think of is
referencing back to my bol app from my dal app(this would allow me to return
native bol app entities) but that sort of negates having seperate apps for
them in the first place.
Basically I'm returning datasets or results as parameters from the dal to
the bol, then map them into the bol apps entities, how would you guys achive
this with some level of abstraction....?
regards,
JCC.
User submitted from AEWNET (
http://www.aewnet.com/)