Handling Multiple Areas for Enterprise level Application

Saravanan V

Hi,
In one of our client place, an existing Enterprise level application with 150 modules developed using ASP.NET 2.0 is being revamped with ASP.NET MVC.

The new solution has the following structure:

Web UI ( MVC Project )

Areas

Module1-Area
Module2-Area
Module3-Area

Core
Entitities
Business
Data

The current production environment is comprised of four WFE servers and one load balancer.

Client wants to have the same Authentication and Branding logic across the modules under the same solution. As of now, team is working on three modules using the Areas concept and going forward other modules would be added as and when possible.

The question is, what is the best practice to handle this kind of scenario? do we need to keep the modules under Areas and continue adding additional modules going forward or do we need to have a separate project for each module under the same solution?

If in case keeping them as separate project is the good option, how about handling build and deployment process?.

The constraint what we have is client doesn't want to have multiple solutions.

Experts advise please.

Thanks,

Saravanan

6 Replies

Know the answer? Post it — somebody with the same question will find it here.

Nilesh Shah9y ago
Accepted answer
If you are sure you will need 100+ areas, then it's better to use separate projects.

Even Microsoft suggests that.

I think the following link may help:
https://forums.asp.net/t/1834134.aspx?Areas+as+Separated+Projects+
https://msdn.microsoft.com/en-us/library/ee307987(VS.100).aspx

please mark my answer as accepted if it fulfils your questions.
0
Saravanan V9y ago
Thanks for your update.
I have also figured out the MSDN link and was trying to execute the walkthrough steps.
I have gone through till the step "Adding Area-Enabled Link to the Logon User Control" and having problem at the step "Enabling the Custom Build Step for MVC Areas Projects" as couldn't able to find the lines as per the walkthrough.

Anyways, thanks for your valuable inputs and time.
0
Saravanan V9y ago
Ok. We are sure that we are going to hit the number 100 going forward.
The article what I had seen online tells about keeping the respective Area code files as separate project and create .bat file to copy the view files from each project to the main web project during the build and it was not satisfactory to me considering the build and deployment process.
0
Nilesh Shah9y ago
I have worked on a big MVC project which has at least 35 areas to represent different modules. But there was not problem at all.

I think if it worked for 35, then it may work for 50 or 100 as well.

If you want to have multiple MVC projects then also it will create problem in URL redirection, etc. because that project is your entry point.
0
Saravanan V9y ago
Hi Nilesh,
Thanks for your kind response.
Actually, client is a technical person and also the final authority on approving the technical stuff.
Each module is different from the other for sure and what is being tried out is to reuse the same authentication, branding etc., for all of the modules.

As per the suggestion, let's say modules are being added under Areas in the web project. Going forward, when there we encounter a situation to have 50 or 100 modules, would it be good to continue as such?

Do we have any drawbacks on this approach when we have huge number of modules under Areas?
What would be the key decision factor to finalize the approach?

Thanks,
Saravanan
0
Nilesh Shah9y ago
as far as MVC is concerned, I suggest to keep different modules in areas.

the seggregation should not be at user requirement level, but it should be at technical level

you can further make different projects according to different business logics
0