Multi site question

[Griff]

Investigating possible architecture for an ASP.NET web solution.

I am familiar with the architecture of two multi-site systems. Neither are
by any means ideal. One is pure Classic ASP and the other is Classic ASP +
VB6 DLLs.

Pure ASP: This utilised a complete copy of the ASP code set for each
customers' site.

Mixed ASP + VB6 DLLs: This utilised a separate site for each customer's
site that contained a single ASP page. This page simply called a public
function in a common DLL which returned an HTML string. The DLL knew how to
format the page based on the referral URL containing the ASP page.

Now, what about an ASP.NET solution? I'd obviously like to centralise all
common code, and to this extent it's obvious that I'd centralise the
business and data tiers. However, I'm assuming that I'd have to put all the
ASPX pages (UI) in each dealer's site, despite the fact that many of these
will be identical. The page controller stuff (UI Process block) could
either be common or duplicated. Does anyone have any suggestions as to
which way to go?

Many thanks

Griff

 

[Jeff Cochran]

Investigating possible architecture for an ASP.NET web solution.

I am familiar with the architecture of two multi-site systems. Neither are
by any means ideal. One is pure Classic ASP and the other is Classic ASP +
VB6 DLLs.

Pure ASP: This utilised a complete copy of the ASP code set for each
customers' site.

Mixed ASP + VB6 DLLs: This utilised a separate site for each customer's
site that contained a single ASP page. This page simply called a public
function in a common DLL which returned an HTML string. The DLL knew how to
format the page based on the referral URL containing the ASP page.

Now, what about an ASP.NET solution? I'd obviously like to centralise all
common code, and to this extent it's obvious that I'd centralise the
business and data tiers. However, I'm assuming that I'd have to put all the
ASPX pages (UI) in each dealer's site, despite the fact that many of these
will be identical. The page controller stuff (UI Process block) could
either be common or duplicated. Does anyone have any suggestions as to
which way to go?

Separate business logic from presentation logic. Business logic goes
in the back end.

Jeff

 

[Griff]

Separate business logic from presentation logic. Business logic goes

in the back end.

The User Interface (as in the View) is obviously part of the presentation.

However, are the User Interface Processes (the work-flow, navigation etc)
presentation or business logic?

Griff

 

[Jeff Cochran]

The User Interface (as in the View) is obviously part of the presentation.

However, are the User Interface Processes (the work-flow, navigation etc)
presentation or business logic?

Navigation is always part of presentation, work flow might be (I
suspect you'd have some in both). And generalities don't always fit
anyway. Business logic may say that all phone numbers are ten digits,
and that's best handled in the UI and enforced on the back end. The
UI only allows ten digits, and the back end only accepts ten digits.
The logic fits in both places.

But in general, presentation logic is separated to ease updates in
look and feel, as well as allow for multiple client versions to be
developed. The business logic is coded on the back end to both
restirct potential user abuse, if they can't get to the code they
can't fiddle with it, and also to allow for simple changes. Such as
when your company goes global and now needs country codes in the phone
number fields.

Jeff