Web applications - merge or split?

Question

For our company, I am creating a large Extranet website, which will present a set of sub-applications. I am a little puzzled by what should be the correct setup of the solution and projects.

I have one web application that we call the Portal. It contains authentication / authorization classes, master pages, navigation routing and URL classes, and topic definitions. It will also contain some basic reviews for our clients to get a brief idea of ​​the status of the project.

Next year we will develop and integrate more applications with the portal. Think of it as detailed reviews and tools called functions A, B, and C. Over the years, we have been improving these applications and releasing new versions. These web applications fit seamlessly into portal navigation. I would like them to reuse master pages and themes.

What is the correct way to customize this solution?
How can I link applications together, reuse master pages and maintain them in service?
How can I exchange certain webcontrols (ASCX) appropriately?
We use TFS, perhaps any branching / merging ideas?

Edit:
I would like to create it in ASP.Net WebForms, we have the most experience in this area. But basically we can use something, we have our own server under our control (as long as it is focused on Microsoft, and does not switch to php or something like that :))

Answer 1

What is the proper way to setup this solution?

The right way ... There are so many. I have seen many applications and many different settings (many of which I consider to be "correct"). What you are really asking is the best way for your situation.

As you build the portal, you will have the luxury of separation of functions, which will help you in developing additional functions for your application.

I would set up one website with a separate folder for each function. Creating a single website will allow all functions to share the same master pages, usercontrols and configuration file - without having to do anything special. (In this note, I would put all your master pages in a folder on my own and create another folder for your user controls).

How can I tie the applications together, re-use the master pages and keep it maintainable?

Again ... folders are the best option here. Folders will help to separate each function, simplifying application management.

How can I share certain webcontrols (ASCX) in a proper way?

First of all, ascx files are not webcontrols. They are users. WebControl is a class for creating server controls that are in a separate assembly. As for usercontrols, as I said above, if you put them in a separate folder, they are always in one place and available throughout the application.

We are using TFS, perhaps any branching/merging ideas?

There really is nothing special here. There are many different paths you can take regarding branching:

• One of them is to create a branch for each version.
• Another is to create a branch for each new function you add (in your case, this is almost the same as the first option).
• Another is to create a branch for each developer.

When I decide how I am going to deploy my code, I think about what will protect me the most. In your case, you need to plan for bug fixes between feature releases, so perhaps one branch after each version makes the most sense (call it the dev branch). However, given the separation of functions, one function may not affect the rest of the application. You may not need this fork to be safe.

Answer 2

According to Brian, when creating a public API, you should fix it as much as possible, which means that after the initial version it should change as little as possible. However, to do something that is stable requires a lot of effort, so if you are not ready to use the API, you should internalize it as much as possible, and for this reason you may need to combine things more than separate them.

However, I am not going to propose an architecture appropriate for your application based on the description of paragraph 5. What you need to do is to weigh the pros and cons of several large projects against having a small number of small projects. I mean, the more you plan to do, the easier it will be on the line if you stick to the plan.

Thus, contrary to Brians' answers, I would not recommend that you make your whole system “as less connected as possible,” just because you make it as loosely coupled as it should be .;) Short-linked code can cause as many problems, how closely related code if you abuse it.

Cm:
1. Which is better, many small assemblies or one large assembly?
2. Specific downstream sides for many-max assemblies?

In the end, only you know how much you want to focus on each of the "... features", maintainability, extensibility, reliability, etc. So, plan your priorities and tasks correctly and correctly.

Regarding branching strategies, you can read the TFS Branching Guideline 2.0 , which is very familiar with various branching strategies, from basic to advanced. Even if you are not using TFS, this is a good read guide (I am using SVN at the moment). Since I currently work in small groups with 1-4 developers, I tend to use a strategy that is between basic and standard. Not that I recommend this for you, but it works best for our team.

As for the exchange of codes between projects. In SVN, we can use " externals ", which means that the shared file will be displayed in several folders, so when you change one copy and commit change to svn, all other copies will be updated in the next svn update. However, I cannot remember if TFS has anything like that.

Note: Beware of external ones in SVN ... they can cause ... problems .;)

My advice is to try to avoid sharing aspx, ascx and master pages as much as possible. Usually it hurts a lot more than it helps. Instead, try using inheritance or other alternatives to achieve your goal.

ASP.NET MVC 2.0 has a concept called "Regions" where you create subsections of the application in isolation from the rest. As far as I know, these areas can be supported in separate projects from the "main" application. This sounds very similar to what you are requesting, so maybe you should study this.

Hope this makes sense .;)

Answer 3

I would like to see your system as flexible as possible. When / when you add more applications, your site will become less and less reliable (since no component will increase in 100% of cases, combining them will reduce overall reliability). Thus, you must create your own system in order to serve non-essential services (I believe that the Amazon home page, for example, has 100 services that contribute to it, and therefore it is built on fault tolerance)

Your APIs between services should remain as stable as possible, so implementations can change without breaking the link. You should also explore the automated testing of this at the web level (perhaps Selenium or the like?), Since testing individual services will give you a little coverage of the overall behavior.

Answer 4

You may find it helpful to take a look at the implementation of the custom VirtualPathProvider . In my last project, we had several ASP.NET sites that needed to share theme files (main pages, user controls, images, style sheets), so I created VirtualPathProvider, which allowed us to map a virtual folder (e.g. / Themes) with any physical folder on your hard drive (for example, C: \ Shared \ SiteThemes).

This is not trivial, but not too long and did not cause any problems. By the way, it turned out that this is a great way to overcome the maximum component limit in WiX ... Please note: you cannot precompile sites that use VirtualPathProvider.

Answer 5

Use MVC concepts from now on. they provide greater scalability and flexibility for robust applications.

Answer 6

You can look at using SharePoint. This is a pretty decent platform for delivering ASP.NET applications, especially if they coexist in an intranet environment; It gives you a lot of stuff for free.

Of course, he has very rough elbows, so to speak, so be careful.

Answer 7

I would not consider applications as separate, but as modules of the entire portal.

I would recommend you take a look at MEF, as that would seem to be perfect.

http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx