"Sam" <(E-Mail Removed)> wrote in
news:82BB681E-D0CF-4EAC-B3F7-(E-Mail Removed):
> 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?
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! |
*******************************************
Similar Threads
