Web application architecture using 2.0

  • Thread starter Thread starter cschuman
  • Start date Start date
C

cschuman

Currently there are 60+ web applications at my shop. The applications
have similar functionality just different parameters. We are about to
go through a reskinning process. I would like to create a master
application that contains all UI elements (such as parameters,
datagrids, charts, etc.).

Taking this approach, a developer would create a new application by
creating a code library project (instead of a web application). When
compiled the business logic would be in a DLL. To deploy the new
application the newly created DLL would be added to the master project.

To determine which parameters to display there would need to be an XML
doc describing what controls to display.

So, in the end there would be 60+ business object DLL's in a master
application. All applications would use the same controls, making
functionality consistent.

What are some of the pit falls associated w/ this approach? Is this a
viable option? Would it be better to have 60+ separate web applications?
 
Hello (e-mail address removed),

We have the same architecture for internal project, and it's really viable.
There is a site backbone where new developed components (dll + associated
XML with menu items) are integrated into that framework.
Besides, you can provide SDK to add some components to your site dynamically
(smth like the live.com)

I see no problems with such approach

I see the advantages of this in the style and architecturing integrity
Currently there are 60+ web applications at my shop. The applications
have similar functionality just different parameters. We are about to
go through a reskinning process. I would like to create a master
application that contains all UI elements (such as parameters,
datagrids, charts, etc.).

Taking this approach, a developer would create a new application by
creating a code library project (instead of a web application). When
compiled the business logic would be in a DLL. To deploy the new
application the newly created DLL would be added to the master
project.

To determine which parameters to display there would need to be an XML
doc describing what controls to display.

So, in the end there would be 60+ business object DLL's in a master
application. All applications would use the same controls, making
functionality consistent.

What are some of the pit falls associated w/ this approach? Is this a
viable option? Would it be better to have 60+ separate web
applications?
Click to expand...
---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsch
 
Michael said:
Hello (e-mail address removed),

We have the same architecture for internal project, and it's really
viable. There is a site backbone where new developed components (dll +
associated XML with menu items) are integrated into that framework.
Besides, you can provide SDK to add some components to your site
dynamically (smth like the live.com)

I see no problems with such approach

I see the advantages of this in the style and architecturing integrity
Currently there are 60+ web applications at my shop. The applications
have similar functionality just different parameters. We are about to
go through a reskinning process. I would like to create a master
application that contains all UI elements (such as parameters,
datagrids, charts, etc.).

Taking this approach, a developer would create a new application by
creating a code library project (instead of a web application). When
compiled the business logic would be in a DLL. To deploy the new
application the newly created DLL would be added to the master
project.

To determine which parameters to display there would need to be an XML
doc describing what controls to display.

So, in the end there would be 60+ business object DLL's in a master
application. All applications would use the same controls, making
functionality consistent.

What are some of the pit falls associated w/ this approach? Is this a
viable option? Would it be better to have 60+ separate web
applications?
Click to expand...
---
WBR,
Michael Nemtsev [C# MVP] :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do
not cease to be insipid." (c) Friedrich Nietzsche
Click to expand...
I suggest that you model the requirements of your applications to
reflect some domain knowledge. Your dll's could reflect various objects
in your domains and may be shared. As to what to display, you may
control this via configuration settings for each application. I very
much like to use IoC as in
http://www.thejoyofcode.com/The_Awesome_Power_of_IoC_Part_III.aspx

Good luck
 
Back
Top