Another N-Tier Question

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have been reading up on the N-Tier application Design Model.

I understand the concept of and the purpose of breaking up the application
in to
seperate modules (or tiers) for reusabillity and ect.

What i dont understand though is what exactly needs to be on a data access
tier.

For example I am working on a project right now that i was thinking of making
Tier 1: UI (Asp.Net)
Tier 2: DA (Class Library)
Tier 3: Data (Access Database)

so i am assuming obiously that the ui tier is where i would put the design
of the asp.net pages
but what do i put in the data access layer just the data needed to retrieve
and update data

i would have to put some stuff in the ui layer like for example

if i were to make a page transaction that is a new transaction for a ledger
page
i would get the information from the asp.net page that i made to get this
information from the usrer
and then i would send that to the data access layer is that Right?

I quess what i am asking is that i understand why to use the N-Tier Model i
just dont understand
neccesarily how to implement it.

Also, what is best for this sort of project.

do i just at runtime load the datainto a dataset and then break it up into
collections of user defined types
that i have created or should i just use a database project and just use a
bucnh of scripts?

WStoreyII

Thanks Again For The Help
 
WStoreyII,

You are sure you want to go this way to learn something, far in past I
believed in the true N-tier applications. The result from those are in my
idea however often huge impossible to maintanance applications.

In the Net are a lot of inbuild features for things like by instance
concurrency. When you start with an N-Tier application you start with
retrieving the data what is quit simple. However when you want to set it
back and handle all concurrency problems you have to do a huge amount of
work and it becomes everytime more and more because you have to transmit the
errors to the UI what is standard build in between ADONET and UI.

When you keep in mind that an ASPNET applicication is stateless than you
know that you have to save the state of the data you have sand to the page
somewhere. Some times I read you can reread it, however what than when it
has changed meanwhile, how do you recognize that.

Therefore you can use the session or the viewstate. Where when it is a huge
amount of data the viewstate is only to use when you know it is only for
IntraNet.

Using the cache or your own shared class for this will give you only
overhead, because the data stays as well in the servermemory while you than
have to build your own mechanisme to get that, and the only solutions for
that are using again a key saved in a session or for that more properiate a
viewstate (the cookie can as well, however I would never do that anymore
because of security issues). However what is more a problem, you have to
clean it up when the user does not end in a decent way, what is with a
ASPNET application more than normal.

I can go on, however this is only a message to tell, to think twice before
you begin. I also can tell that I for myself am not clear what is the best.

However just my thought at the moment about this.

Cor
 
I wouldn't use Access for any kind of ASP.Net application. Its an absolute
dog of an engine in multiuser environments.
You're setting yourself up for some major performance headaches down the
road. You want to be looking forwards not backwards.
Check out SQL Server 2005 Express edition. Its free and replaces good old
MSDE. XCopy deploy/GUI tools the whole 9 yards.

Of course you may have to ask your ISP, assuming you use an ISP, when they
plan to support it etc but if your only in the design phase now
then stop and reassess that decision to use A2K for ASP.Net. If its an
intranet app, i'd be in boots and all on 2005.

As for nTier partitioning: simply put if you cant switch from A2K to SQL
Server without breaking your app you have too much/too little in your
DAL/middle tier.
DALs only purpose is too put the data in and pull the data out. Its middle
tiers job to shake it all about. If you've never done it before then just do
what you think, maybe you'll cock it up a little but thats generally the
best way to learn. Textbooks will teach you the how, experience will teach
you the why?

Just make sure you implement a good messaging system to communicate error
handling/logging etc.
Its really quite straight forward.

Richard
 
Back
Top