In what order should we implement Asp.Net Mvc App

Question

This might be odd question but I am just goig to start a new Medium size WebApplication using Asp.Net MVC.

Every person has his own approach towards a solution, but there are always some practices followed.

While Working With Asp.Net Forms Application I always, worked in following order

• Database
• Data Access Layer (LinqToSql / Ado.Net Entities etc)
• BLL(Business Logic Layer + Business Objects)
• Front End ( Forms, design etc and)
• Authentication, Testing (integration) and others etc

(parallel unit testing starts with BLL)

Now I have finished MVC books and tutorial and about to start working on Application. Database is the already there. I will be using LinqToSql for DAL (Model(s)).

What Order Should I follow for the implementation of Model, View and Controller. I am confused as all tutorials have different approach.

Like. some start from routing table, some start from Controllers Component, then touch Views, then advise to shift the logic into models, "If Controllerskeep on growing".

Some Teach to work on Sets of Controller --> View(s) --> Model(s), for every process in the specification.

I am not sure what is the right approach. It would be great to have word over the order you use to implement your components / stages. I am also not sure about stage for starting unit testing.

I have tried to make myself clear, please do ask if not sure, You are welcome to edit title or the post itself, if you feel that would be better.

NOTE: will use C#, Sql Server 2005, JQuery, CSS, Visual Studio 2008 and a team of two, beta version and expected several revisions (components). Thanks

Answer 1

I tend to start with the user interface and work backwards. This is so that I can work with users and business analysts as I build up the application. I have outlined the general process in this post.

Answer 2

The real benefits of ASP.NET MVC is that you can leverage Test Driven Design to very cleanly build solutios; so I recommend you start from tests and move backwards.

http://weblogs.asp.net/shijuvarghese/archive/2009/07/22/introduction-to-test-driven-development-with-asp-net-mvc.aspx

http://www.wrox.com/WileyCDA/WroxTitle/ASP-NET-MVC-1-0-Test-Driven-Development-Problem-Design-Solution.productCd-0470447621.html

http://elijahmanor.com/webdevdotnet/post/ASPNET-MVC-10-TDD-Book-Review.aspx

Answer 3

That depends.

1. Start from database if you've already got one and that's the big part of the application. Use Entity Framework in this case as it's more data-centric.
2. Start from user interface if you've got complex UI and users that can provide you a feedback.
3. Start from entities if business logic is the king and UI is a second-class citizen. This will help with things like TDD/DDD.

I think you can combine 2/3 and integrate them at some time. If you base one on another (UI on domain objects, or vice versa) they may influence each other which is not a good thing. For example, I used to design my ViewModels after domain entities and that caused convoluted views/view models that inherited a lot of domain entities design.

Doing UI independently will help in quick feedback and well-designed views and models. Doing domain level independently will help in keeping solid core design. Doing both independetly will provide you with 2 points of view which is, like stereo-vision, gives a lot more details on the whole picture. The key here is the communication - between domain and UI developer(s) and the customers.

Answer 4

When sitting down with members of my team and scoping out the components of a piece of functionality they have assigned to them, they tend to work from top to bottom because they feel more comfortable starting by defining what they need through that approach.

We employ a TDD approach to development, and when writing their tests, the developers typically start by writing a unit test for their new controller action, dictating what its behaviour should be and from that typically work out the dependencies required.

This might involve creating new classes/methods and they do that as well as creating the interfaces and passing the interfaces into the controller (heavy use of IOC).

That gives them the next level of interfaces to write tests against, and the same approach is then taken of writing the tests first, working out any necessary dependencies (and creating them if necessary).

Tests can still be written against mocked up versions of those interfaces, so there is no need to go writing your implementation until you've also written the tests against those interfaces.

This means we have 100% coverage from top to bottom and the result is often a well thought out solution to a problem.

When I approach a problem, I'll often start from the bottom because I already have it all mapped out in my head and on paper, but I can see the benefits of the above approach - less likely to end up falling into the YAGNI trap and you end up with only the code you need.