Structuring of large application

[Damien]

Hey guys,

I'm currently developing a reasonably sized application, which is
expected to grow in the future.

At the centre is the User login facility - everyone using the site must
log in. Thereafter, various different services may be available to the
user, dependant on how they are set up - there are currently two
services available:

Creditor Services
User Management

Because there are a lot of tie-ups between the services, and a lot of
shared data, all of the data resides in a single database (but
service-specific information is stored under separate schemas). A
single data-access layer provides access to the database, and the
services share session management facilities.

At present, because of the large number of tie-ups between the
services, the system is structured as a single monolythic web
application.

I tried to break it down a bit by placing service specific pages within
subdirectories. However, ASP.NET couldn't seem to cope with this, and
couldn't manage to create/find the code-behind associated with these
pages.

Even if I split the services out into completely separate web
applications, I still want them to be able to share session information
and there are a fair number of common pages/common code between them.

How would you guys suggest I go about restructuring, before the next
service comes along and makes the job even harder?

Ideally I would like the common login facility (and initial service
selection) pages to reside at the root of the site, and then for each
service to reside within a (virtual) directory below that.
Any pointers?

[Brandon Potter]

Have you thought about possibly writing the business logic & data layer in
one application as a web service, and writing the UI in your regular web
app?

Sometimes people will assign a GUID to a user at the start of a session and
keep their current session's login information in a database, and simply
pass the GUID along to another application when they "jump over the wall",
so to speak. Again your central login database could be another web services
app.

Brandon

"Damien" <Da************ *******@hotmail .com> wrote in message
news:11******** **************@ z14g2000cwz.goo glegroups.com.. .

Hey guys,

I'm currently developing a reasonably sized application, which is
expected to grow in the future.

At the centre is the User login facility - everyone using the site must
log in. Thereafter, various different services may be available to the
user, dependant on how they are set up - there are currently two
services available:

Creditor Services
User Management

Because there are a lot of tie-ups between the services, and a lot of
shared data, all of the data resides in a single database (but
service-specific information is stored under separate schemas). A
single data-access layer provides access to the database, and the
services share session management facilities.

At present, because of the large number of tie-ups between the
services, the system is structured as a single monolythic web
application.

I tried to break it down a bit by placing service specific pages within
subdirectories. However, ASP.NET couldn't seem to cope with this, and
couldn't manage to create/find the code-behind associated with these
pages.

Even if I split the services out into completely separate web
applications, I still want them to be able to share session information
and there are a fair number of common pages/common code between them.

How would you guys suggest I go about restructuring, before the next
service comes along and makes the job even harder?

Ideally I would like the common login facility (and initial service
selection) pages to reside at the root of the site, and then for each
service to reside within a (virtual) directory below that.
Any pointers?