Best way to merge two identical ASP.NET web sites?_问答_开发者

We have two websites which only difference is in the design (different images, styles, layouts..etc) but the web structure of files and cs code is the same so we want to simplify its maintenance...

The actual structure would be:

DefaultA.aspx
  DefaultA.aspx.cs
DefaultB.aspx
  DefaultB.aspx.cs
LoginA.aspx
  LoginA.aspx.cs
LoginB.aspx
  LoginB.aspx.cs

One idea would be changing the design differences at runtime depending of the origin website, but we dont like much this because performance, abstraction in designing them and url confusion...

开发者_运维百科Another one is sharing the cs (both aspx inheriting and using the same cs) file but we never have done or seen it done in any website before so we wonder if its a good approach...

What do you think? Any other way better in terms of performance vs development-ease?

Maybe I'm confused by your question, but if you have two websites that are truly exactly the same, other than images/style/layouts - why not delete one of the sites and just use some CSS magic to show two different sites depending on which address is visited by the user.

if it's only layouting which changes but not functionality I would advise to go for different Themes. Depending on some logic, like a Role or something in Profile, you can then opt in the OnPreInit event of the page to set the Theme in code.

Besides that I would also suggest that you have every codebehind page inherit from a custom class which inherits itself of the Page class. Write the OnPreInit code, to set the correct theme, in that custom class so you only have to write it once. All your other pages inherit from that class and benefit of the dynamic Theme setting. Btw, you can also use that same technique to dynamically set Master pages.

Grz, Kris.

I've had a simliar scenario whereby I have created .net controls that had to have alternative markup and appearances in different sites. Simply applying different CSS rules and themes was not enough as the markup of these controls could change drastically depending on the design documents etc.

I found that the best approach was to identify the common controls or pages and then migrate their code behind into classes which were stored in a seperate assembly. This is actually very easy, you simply have to recreate the code behind class as a new class within your assembly and ensure that the inheriting page / control references the assembly.type as required. Once this is complete your existing site will function as before but you will also have seperated your control logic from the UI layer.

Now you have an assembly that you can drop into multiple projects and all you have to do is add a new control / page which inherits from your assembly / type rather than having multiple code behind files all doing the same thing over different website. The important thing is to make sure that any sub controls you reference from your page are present in your markup in order for ASP .Net to wire up the controls to the code behind instances during the page life cycle.

Another one is sharing the cs (both aspx inheriting and using the same cs) file but we never have done or seen it done in any website before so we wonder if its a good approach...

In the end we took this route and up until now we havent had any problems, its easy to mantain and if you add new controls in the A site the compiler warns you about adding them to the B site...

You've already accepted this as your own answer, but I would like to offer you how I handled a similar problem previously in converting two "identical" websites into a singular project to handle both. I had two separate web domains hosting almost identical applications formatted to separate brands for different companies. I needed a single solution with common code that would be able to serve, function and log independently based on the domain being served.

First, we created base controls (base page, base user control) that housed all of the business object data we would need regularly (session, viewstate, basic properties, anything we knew we'd need universally). Within the base page in our class library, we created a property to identify which site was being served (scalable as this is an enumeration).

In the actual structure, we created a folder for each company that needed its own branded, and inside there we created the actual aspx pages that assigned master pages that governed style and branding. Within the master pages we included our user controls. All of our application controls were built with styled user controls. This way the functionality of the actual application is held in the same place, but it can be called for multiple brands. On top of that, there were minor differences to the applications depending on the brand. These exceptions were coded into the user controls so that they could be easily identified for future maintenance, and in some cases a user control was used solely in one brand for a specific purpose.

This segmentation has allowed us to keep the site map a little cleaner, provide multiple interfaces to the same application without having to rewrite the application, and with the base controls/pages we have been able to make development easier for anyone new to the team. Once they're familiar with the base classes and architecture layout, they can find anything in the site to which they are assigned.