How to split up ASP MVC Project using Code-First Entity Framework

Question

For an academic exercise, we have been tasked with creating a small website. We have already gathered the requirements and fleshed out the business domain to see the classes we are supposed to support. It is to be on Microsoft stack, so I decided to use ASP MVC with code first Entity Framework. I am now looking for the best way to split up a 6 man team in order to best tackle the project.

TLDR: What are some effective ways of splitting up an ASP MVC project so that multiple developers can work on it concurrently?

I have researched where projects have been split across the tiers, i.e. database, business, views, and such, but I don't exactly know how to instruct them to go about designing a view for which there is no controller.

Is splitting it up between the different business models used a decent strategy? I have read that this has led to an application that didn't mesh well, due to the different aesthetics.

Answer 1

The way our small team approached the problem was to cooperatively develop the domain layer and database logic, and then proceeded to split the work up by Area, so I worked on settings while another person worked on our core CRUD pages. Once that was done we picked another area and off we go again. There are several problems with this approach:

• Our initial development work produced views that didn't look at all similar. We had to go back and redo the views. This could be avoided by having specifications and design work done thoroughly beforehand (we are doing this now, and it makes things much better).
• We both developed library methods to do the same thing independently, and refactoring was needed to remove the duplicate (this was sometimes easy, but often difficult as we wrote them quite differently).

If I had my time again I would do the following:

• Write your business logic together and decide on URL endpoints (controllers and actions and their arguments). If you are using separate business entities and MVC models, design the MVC models too.
• Now one person can write views based on the MVC models and for the URLs decided upon, whilst another person would write the controllers/actions necessary.

That's not perfect (can't really test the views until the controllers are written) but it does minimize interaction so more work can be done faster.

Another option (although not true MVC) is to write the application as a single-page application, and have one group write everything behind the REST API, and have another group write the JavaScript on the front-end.