jfreethan
jfreethan

Reputation: 41

Multiple MVC projects structure

I need help designing a MVC structure for use in a team environment? Here is a short explanation of what we are doing:

Options:

  1. I can setup a normal MVC solution in Visual Studio for each module. So I could have a VS Solution for Census, one for Pipeline, etc. That is all fine but I want to have a shared view(s) that can be used across projects (similar to a Master Page). How would that work in this scenario?
  2. I can setup one MVC application that has Areas for each of the departments. Not a bad option. It solves my shared views issue. However, I could end up with 12-15 different areas by the time we are done. That is a lot of sub folders and code in one huge solution. Not to mention the fact that I might want to separate my Model & Repository out into their own projects. Could that even be handled using Areas?
  3. If there are better idea for this, I'd appreciate help.

We have 8 - 10 developers who will be working on this application(s) moving forward so I just want to make sure I have the best structure possible.

Upvotes: 4

Views: 802

Answers (2)

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93454

You can really do this in any number of ways.

One option is to use Portable Areas, where each area is it's own assembly. This can solve your project size issues.

Upvotes: 0

Ivan Pintar
Ivan Pintar

Reputation: 1881

I think there's no "right" answer here, basically it boils down to what you think will be easiest to build and maintain over the course of time. So here's what I'd do.

Combine the modules into more manageable units and have those in different website projects where the modules would be areas. If the view sharing is the most important thing here, then this would be the criteria by which you'd group the modules into a website with different areas. Also if they share some views, chances are that they are also logically more or less similar, so you'll end up grouping them by their logical meaning too. You could then have these as different projects in a solution, or different solutions altogether.

There also seems to be a way of using views from different projects. I personally have never done it, and the link is what a quick Google search gave me, so be sure to go over it in detail. This could make your views reusable across all websites.

About the models and repositories, I'd have them in a completely separate project which would then be referenced by all the websites. More recently I tend to build my models and repositories without any kind of "client" in mind, so I usually put them in a completely separate project, and I try to build them so that they can easily be used by a website, a web service or a desktop app.

I hope this helps, but as I said, it is by no means a right answer (and it could be completely wrong, so if someone has a better idea, please do share). By the way, if you have 8-10 developer who'll be working on it, be sure to ask them. A bunch of different opinions from smart people tend to blend into useful ideas.

Upvotes: 1

Related Questions