Architectural design question - please advise

[Griff]

Hi

I'm not sure of the best way to go about achieving my goal and would
appreciate any advice.

What I would like to do is to generate a control that can be dropped onto a
web page. For example, a control that provided catalogue information. As I
envisage this, the control would be given a single argument (the end user
identifier) and it would return the required catalogue information as an
HTML page "fragment".

I'll first describe how I'd design this to work for a simple example; then,
I'll add the complexity that is causing me the design headache.

Simplistic model
-----------------

Imagine that I have three users. They navigate to a web page and expect it
to display a list of products. These users have DIFFERENT product access
permissions, so the only difference would be that the three users would see
different products. Okay, well I'd design the control to have three
layers - presentation view, business logic and data access logic.

The view would simply expect to create (say) a table containing product
details from a recordset.

The business logic would identify which products the user is allowed to see
(either in .NET code or in stored procedures or in DB relational tables)

Data access would connect to the correct database.

I think this is all fairly well understood.

My complicated model
-----------------------

Okay this is exactly the same as with the simplistic model except in this
case users 1 & 2 expect the data to be presented in a table whilst user 3
expects the data to be presented as a tree view (or whatever). So, what
we're really saying is that the view will be dependent upon the user (and
the details of which user wants which view would be held in a database).

My initial thought would be to now have 4 layers.

The top layer would be a user control with no visual aspect itself. It
simply identifies (from business logic) which view the end user requires
(tree-view or table etc). Programmatically it would then decide upon which
view to call. The web page would again just pass in the user identity
argument as before.

The next layer down would be a set of views (the tree view, the table view
etc). These views would all be user controls (I presume) and would all
consume the SAME set of business logic and data access logic.

My question is: Is this 4-tier design the best way to achieve my goal? If
not, what should it be...

Many thanks in advance

Griff

[Cowboy \(Gregory A. Beamer\)]

I am all for separating out the actual user display from the logic to
manipulate that display (a facade layer, if you will), for the following
reasons:

1. Easier to attach unit tests to the code
2. Reusability of UI logic (tailoring multiple sites with similar
functionality primarily)
3. Ability to have two developers work on the same problem (one on UI, the
other on code)
4. Easy to switch out UI (web to windows, for example)

Are you ever thinking or can you conceive different types of UI? No brainer,
do "4" tiers
Can you use the UI logic (code part) in more than one app? No brainer again.
Yes, do it!
Do you have larger teams? Good idea to separate into libraries.
Do you do TDD (nUnit or Team System)? Then separate.

NOTE: If you are not doing TDD? Why aren't you?

One option for your control, regardless of how you divide out your tiers, is
the webpart stuff in ASP.NET 2.0. Using the webpart infrastructure, you can
make this "control" a piece a person can add and you can have different bits
of fucntionality on different parts and have them communicate with each
other.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside of the box!
*************************************************
"Griff" <howling@the.moon> wrote in message
news:OqUFOmL2GHA.1040@TK2MSFTNGP06.phx.gbl...

> Hi
>
> I'm not sure of the best way to go about achieving my goal and would
> appreciate any advice.
>
> What I would like to do is to generate a control that can be dropped onto
> a web page. For example, a control that provided catalogue information.
> As I envisage this, the control would be given a single argument (the end
> user identifier) and it would return the required catalogue information as
> an HTML page "fragment".
>
> I'll first describe how I'd design this to work for a simple example;
> then, I'll add the complexity that is causing me the design headache.
>
> Simplistic model
> -----------------
>
> Imagine that I have three users. They navigate to a web page and expect
> it to display a list of products. These users have DIFFERENT product
> access permissions, so the only difference would be that the three users
> would see different products. Okay, well I'd design the control to have
> three layers - presentation view, business logic and data access logic.
>
> The view would simply expect to create (say) a table containing product
> details from a recordset.
>
> The business logic would identify which products the user is allowed to
> see (either in .NET code or in stored procedures or in DB relational
> tables)
>
> Data access would connect to the correct database.
>
> I think this is all fairly well understood.
>
> My complicated model
> -----------------------
>
> Okay this is exactly the same as with the simplistic model except in this
> case users 1 & 2 expect the data to be presented in a table whilst user 3
> expects the data to be presented as a tree view (or whatever). So, what
> we're really saying is that the view will be dependent upon the user (and
> the details of which user wants which view would be held in a database).
>
> My initial thought would be to now have 4 layers.
>
> The top layer would be a user control with no visual aspect itself. It
> simply identifies (from business logic) which view the end user requires
> (tree-view or table etc). Programmatically it would then decide upon
> which view to call. The web page would again just pass in the user
> identity argument as before.
>
> The next layer down would be a set of views (the tree view, the table view
> etc). These views would all be user controls (I presume) and would all
> consume the SAME set of business logic and data access logic.
>
> My question is: Is this 4-tier design the best way to achieve my goal?
> If not, what should it be...
>
> Many thanks in advance
>
> Griff
>