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 web pages

Hi,

New to ASP.NET. I am in search of resources that show best-practice for structuring web pages. What I mean by this, is how all pages get the same header, footer etc...Are there best practice patterns for this?

Thanks.

MB.No problem here - - it all depends on what you want (code-wise) in your header/footer files...

If nothing is coded specific to (let's say) Classic ASP, then, you can just create include files and use them, just as you did in Classic ASP - -

if you want more robust functionality, that ASP.Net is good at - - then, you might want to look into creating a User Control for each, placing them wherever you'd like on the page.

here's a start for you , concerning UserControls:
http://aspnet101.com/aspnet/headfoot.aspx?code=/aspnet/headfoot.aspx - keep in mind, this is a VERY simple sample, just to give you a look at how it's done...
Thanks David.
David,

Having looked at the link, it is very simple and not very helpful. I am striving for a complex page structure. I want a header, a left panel, possibly a right panel, a footer and the main content in the middle of all this. Plus, I dont want to duplicate any code. As far as I can tell, I would need to create this structure and copy it into all the ASPX files, and simply embed user-controls for the actual HTML. But this doesnt seem very sophisticated. Surely there is a way of removing the duplication, yet retaining the ability to have complex structures defined in one place?

MB.

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