Architecture of my ASP.NET app

[Guest]

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 thatmap to my database entities, items of each type, for example'clientitem' and collection classes that are collections ofitems, for example 'clientcollection'.

A data access layer that uses a component class connected to asql database and uses commands, adapters and datasets to returnmy data to the business object layer.


I've referenced the bol in my aspnet app and get some quiteuseful abstraction from the database using this method, myaspnet app is completely ignorant of any information regardingthe database, field names, anything really.

I've referenced my dal app in my bol app and what I am finding isthat I am now required to tie the business object layer to thedatabase layer, field names etc, I could use field positionnumbers/ordingals but I find this unreliable, confusing andpossibly troublesome, I don't want to tie my bol to my dal, howcan I avoid this? Or am I just dreaming, I realise the rubberhas got to touch the road somewhere, the only thing I can thinkof is referencing back to my bol app from my dal app(this wouldallow me to return native bol app entities) but that sort ofnegates having seperate apps for them in the first place.

Basically I'm returning datasets or results as parameters fromthe dal to the bol, then map them into the bol apps entities,how would you guys achive this with some level ofabstraction....?

regards,
JCC.
User submitted from AEWNET (http://www.aewnet.com/)

 

[garethdjames]

This is a common concern with developing applications.

But do you need any more abstraction, its always woth asking the
question before you start to add more in, more abstraction equals a
more complicated app and more code.

Right with that out of the way there are a number of options available,
I like to use a DAL with a data access layer, the layer would use a
factory pattern so that different data sources are available.

You could also move to a service oriented approach and creat 1 or more
web services that become your data provider, but this would need a
coarse grained approach.

There are some Object Relational Mapping tools out there, some use
runtime reflection and some use configuration files and some create
business entities for you.

In my case I like to have 3 tiers with 2 (or more) layers in the data
tier, one that provides the data access and one that actually maps the
physical database to the objects

 

[Kevin Spencer]

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.



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/)

 

[J]

Thank you gareth and Kevin for your replies.

It's just so easy to produce bloatware rubbish, I don't want to do that, I
want to produce good quality work that I can point at and say 'hey, I did
that.....', even if only for and to myself..... You've certainly given me
something to think about.....

gareth, I think after reading your post I am going to rethink my dal, I just
haven't given it enough thought, I'm going to create one using the idb
interfaces and put a lot more effort, thought and time into it.....

Kevin, thanks for the breakdown of an app architecture in such simple to
understand terms, I'll try to take onboard what you have said. Back to my
Steve McConnell book I think.....

thanks again for your input,
JCC

 

[Kevin Spencer]

Hi JCC,

You're very welcome, and with an attitude like that, you'll go far!

--

Kevin Spencer
Microsoft MVP
..Net Developer
Sometimes you eat the elephant.
Sometimes the elephant eats you.

 

[garethdjames]

Good luck, sounds like you'll go far