D
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?
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?