Best Pratices to Develop three tier Web Site

  • Thread starter Thread starter Sam
  • Start date Start date
S

Sam

Hi,
I gonna develop a three-tier architecture application (web site):
- User Interface (flash,html,css, etc)
- Business Rules (c#,asp .net)
- Data Access Layer (sql server)

I have to develop the only last two tier (Data and Business) while the last
one tier is gonna develop by another person. So, how can I should organize
my work in order to join all works together?

I though someting like this:
Who is developing UI might create a "layout structure"(html and css, etc...)
while I can create Business rules method that are able to return
html(css,etc...) code?
Es.
<HTML>
<BODY>
<ul>
<li>Coffee</li>
<li>Tea</li>
<li>Milk</li>
....
****PUT here something like that in order to fill all information
<%object.getDATA(params[])%>
</ul>
</BODY>
</HTML>

Anyway, Which is the best pratice that should I use to organize my work?

Thanks.
 
I have to develop the only last two tier (Data and Business) while the
last one tier is gonna develop by another person. So, how can I should
organize my work in order to join all works together?
Click to expand...

First, don't think of it as a 3-tier app. The application is the logical
part in the middle. The database is separate as is the UI. Until you
make this paradigm shift, most of what I can write about this will fall
on deaf ears.

As for how to divide work and get it together, there are a couple of
things.

1. Determine how data resides in your application so you can mock up the
passing of data to build the UI while developing the app, in parallel to
the UI. Domain modeling is crucial.

2. The second thing to determine is how the "tiers" communicate, ie, the
contracts. Once you have contracts, you can easily mock up the other
"tiers".

3. Consider unit testing heavily on the app bits, as TDD concepts, with
a bit of Dependency Injection practice allow you to develop the logic.
This is not mandatory, but the practices work well on the application
section (ie, the middle tier) as you can fully take advantage of
mocking.

If this makes sense, you have a basic working model on how to divide the
"tiers" so each person can work.

One thing that generally happens is you end up with some sort of
translation layer from a data access technology to your domain models.
With EF 4.0, you can use POCO (plain old CLR objects), so if you bite
the bullet and run with the beta (there is a Go Live license), your data
guy can take care of the translation without extra bits.

Hope this makes sense and is useful.

Peace and Grace,

--
Gregory A. Beamer (MVP)

Twitter: @gbworld
Blog: http://gregorybeamer.spaces.live.com

*******************************************
| Think outside the box! |
*******************************************
 
Back
Top