Structuring of large application

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?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" <Damien_The_Unbeliever@.hotmail.com> wrote in message
news:1104919015.363665.323740@.z14g2000cwz.googlegr oups.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?

Structuring Site/Solution

Hi All,
I work in a team of three developers. 99% of our work is developing
'applications' for our organisations Intranet - mainly whats become known to
us as e-employee apps, such as sickness/holiday reporting/authrisation,
handling the new starter/leaver processes, etc...the list goes on.
Up to recently, we have been developing in 'classic' ASP, storing all apps
in subdirectories of there own.
We are now starting to develop using VS.Net...We want to get this as right
as we can from the start, hence the following Q's...
- Should the 'site' be one project, or one solution? Or should each app be a
project, or even solution of its own?
- How do we share code? (Previously shared functions etc using include
files) Is this where the global assembly cache comes into play? I've not had
much luck finding documentation about this - I guess 'sharing' code becomes
a whole lot more important now, thinking in terms of building reusable
classes/functions...etc!
- We also need away of sharing chunks of HTML for headers etc...Are ASCX
files the right way to go for this?
I guess the questions arose when we started to discuss when to do builds,
when to deploy from development to live servers etc...We would need to do
this individually, for each application, as we tend to develop apps that
way - One developer will work on one project for X ws, and then test and
deploy.
Hope that makes sense! Look forward to any advice anyone may have.
Regards,
Simon.We used a single solution and a directory for each "module".
Developement is done using the isolated model (ie using IIS on the developer
machine). Once the source is checked in on the build server we have a batch
file that compiles the app as a DLL for each module. It allows to update
indivually each module (and we have also a common support DLLs for common
stuff).
Sharing is really easy. Use user controls for HTML fragments but you could
use just classes to share "pure" code...
Patrice
"Simon Harris" <too-much-spam@.makes-you-fat.com> a crit dans le message de
news:%23720RBwqEHA.1152@.TK2MSFTNGP11.phx.gbl...
> Hi All,
> I work in a team of three developers. 99% of our work is developing
> 'applications' for our organisations Intranet - mainly whats become known
to
> us as e-employee apps, such as sickness/holiday reporting/authrisation,
> handling the new starter/leaver processes, etc...the list goes on.
> Up to recently, we have been developing in 'classic' ASP, storing all apps
> in subdirectories of there own.
> We are now starting to develop using VS.Net...We want to get this as right
> as we can from the start, hence the following Q's...
> - Should the 'site' be one project, or one solution? Or should each app be
a
> project, or even solution of its own?
> - How do we share code? (Previously shared functions etc using include
> files) Is this where the global assembly cache comes into play? I've not
had
> much luck finding documentation about this - I guess 'sharing' code
becomes
> a whole lot more important now, thinking in terms of building reusable
> classes/functions...etc!
> - We also need away of sharing chunks of HTML for headers etc...Are ASCX
> files the right way to go for this?
> I guess the questions arose when we started to discuss when to do builds,
> when to deploy from development to live servers etc...We would need to do
> this individually, for each application, as we tend to develop apps that
> way - One developer will work on one project for X ws, and then test
and
> deploy.
> Hope that makes sense! Look forward to any advice anyone may have.
> Regards,
> Simon.
>
>

Structuring Site/Solution

Hi All,

I work in a team of three developers. 99% of our work is developing
'applications' for our organisations Intranet - mainly whats become known to
us as e-employee apps, such as sickness/holiday reporting/authrisation,
handling the new starter/leaver processes, etc...the list goes on.

Up to recently, we have been developing in 'classic' ASP, storing all apps
in subdirectories of there own.

We are now starting to develop using VS.Net...We want to get this as right
as we can from the start, hence the following Q's...

- Should the 'site' be one project, or one solution? Or should each app be a
project, or even solution of its own?
- How do we share code? (Previously shared functions etc using include
files) Is this where the global assembly cache comes into play? I've not had
much luck finding documentation about this - I guess 'sharing' code becomes
a whole lot more important now, thinking in terms of building reusable
classes/functions...etc!
- We also need away of sharing chunks of HTML for headers etc...Are ASCX
files the right way to go for this?

I guess the questions arose when we started to discuss when to do builds,
when to deploy from development to live servers etc...We would need to do
this individually, for each application, as we tend to develop apps that
way - One developer will work on one project for X weeks, and then test and
deploy.

Hope that makes sense! Look forward to any advice anyone may have.

Regards,
Simon.We used a single solution and a directory for each "module".

Developement is done using the isolated model (ie using IIS on the developer
machine). Once the source is checked in on the build server we have a batch
file that compiles the app as a DLL for each module. It allows to update
indivually each module (and we have also a common support DLLs for common
stuff).

Sharing is really easy. Use user controls for HTML fragments but you could
use just classes to share "pure" code...

Patrice

--

"Simon Harris" <too-much-spam@.makes-you-fat.com> a crit dans le message de
news:%23720RBwqEHA.1152@.TK2MSFTNGP11.phx.gbl...
> Hi All,
> I work in a team of three developers. 99% of our work is developing
> 'applications' for our organisations Intranet - mainly whats become known
to
> us as e-employee apps, such as sickness/holiday reporting/authrisation,
> handling the new starter/leaver processes, etc...the list goes on.
> Up to recently, we have been developing in 'classic' ASP, storing all apps
> in subdirectories of there own.
> We are now starting to develop using VS.Net...We want to get this as right
> as we can from the start, hence the following Q's...
> - Should the 'site' be one project, or one solution? Or should each app be
a
> project, or even solution of its own?
> - How do we share code? (Previously shared functions etc using include
> files) Is this where the global assembly cache comes into play? I've not
had
> much luck finding documentation about this - I guess 'sharing' code
becomes
> a whole lot more important now, thinking in terms of building reusable
> classes/functions...etc!
> - We also need away of sharing chunks of HTML for headers etc...Are ASCX
> files the right way to go for this?
> I guess the questions arose when we started to discuss when to do builds,
> when to deploy from development to live servers etc...We would need to do
> this individually, for each application, as we tend to develop apps that
> way - One developer will work on one project for X weeks, and then test
and
> deploy.
> Hope that makes sense! Look forward to any advice anyone may have.
> Regards,
> Simon.

Structuring of large application

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?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" <Damien_The_Unbeliever@.hotmail.com> wrote in message
news:1104919015.363665.323740@.z14g2000cwz.googlegroups.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?
>