tags:

views:

161

answers:

2

Looking to gather some views on how a web application (Or possibly set of web applications) should be split up (Project-wise)... basically the whole thing is going to be one large site, but the problem arises because it has a variety of modules which each have their own dev/release cycles.

The problem that arises is that splitting them becomes a headache with trying to make the sessions share between sites and embedding shared resources in DLL's but keeping them as one big project is a nightmare from a source-control perspective.

The possible ways to do this that I can think of are:

  1. Have one application and branch like crazy for the work on each module: On a fundamental style basis this seems right, but it would be a lot of branches and merging branches back in all the time would be a nightmare...
  2. Make them all separate applications: The drawback is they all share their master pages and a lot of custom controls (implemented in ascx). I know how to put these in a DLL (Using virtual path providers), but it's a fairly messy solution. On top of this is passing the session back-and-forth between the applications essentially building a homebrew session solution...

Another thing I tried to find out whether I could do but failed was to somehow have a "virtual folder" of sorts in the csproj so that for example the "ModuleA" folder actually mapped to "../../../ModuleA/Trunk/". I'm relatively convinced this can't be done without using some kind of pre-build scripts but I was hoping for something that'd actually load appropriately in Visual Studio so I think this idea is a no-go...

Does anyone have any advice as to which way I should go with this (Whether it's one of the above or something I haven't considered)? Want to make sure I don't shoot myself in the foot here cause it's likely to be a long-term project with a lot of future enhancements/maintenance...

A: 

If you are building project i am not sure if that's a good idea to use asp.net 2.0, because of the issues you've got. At some stage in my project i moved these ascx controls to separate 'controls library project' that just gets me html strings which i then put somewhere in the website. Like use <%= fControl %> syntax inside aspx pages which i fill with that code. Not elegant solution, but made things much easier. Anyway we decided to reimplement project in php, as it is cheaper and not making such problems.

pablox
Hey, I've already got ascx's working from dll's running as-per-usual (Only weird thing is the source path for the ascx, but even that's fine). Also we're using asp.net 3.5, that's pretty much set-in-stone because as a company that's what people know and retraining the whole company for this project isn't exactly viable.
Tim Schneider
+3  A: 

I have done that in one of our project. There are definitely certain issue we faced during development but it is definitely worth to separate project in separate dll for maintainability

As you have also suggested for virtual path provider i am having certain link for the same which may help you. Also to pass data between two modules we have created properties in interface and created separate project for interface and all the modules implement that interface, so we can pass values from one module to onther module.

Also, it is always advisable if you are building modular application then it should be independent from one another but finally it depends on your requirements.

Link1

UC From Database

Certain links for session sharing between App (I would not suggest to share session but still if you want you can go through this articles)

ASP .Net Forum

Using State Server

StackOverflow

Harryboy
Your view seems to pretty much line up with the conclusions I came to when I tried to work out how to lay it all out. I agree that directly sharing the session like described in some of those links is a dirty hack - so much so that I would write my own session controller before implementing those solutions. As far as making the modules modular enough not to share data go, each module is 100% separate from any other module but they're fairly intrinsically tied to a central application that'll be running in the webroot (Which is basically just a framework the modules tie into).
Tim Schneider
PS: Not going to accept this just yet - would like to give it a little more time to see if anyone has an alternate opinion/approach. If nobody else chimes in within a day or two I'll likely accept this.
Tim Schneider