I have to build a new application from scratch, so I want to implement it using MVC3 and try to follow general best practices as closely as possible. However, I'm developing it as a one man army. Does it make more to create the views first so I have some "Mockup screens" then build the Models and controllers? or the other way around?
4 Answers
I tend iterate through both in turns.
I usually start by sketching the model, since at the end of the day it's the single most important thing to get right in the long term.
But I also consider the UI, wondering how the latter impacts the model. There are occasions where the model is right on paper but leads to either or both of UI problems and performance problems. I adjust the model accordingly.
Take users and addresses for instance. The natural idea is to normalize the thing to the point where you've users, addresses, cities, states, countries, and a user2address table for an n-n relationship.
But if you consider UI implications of that and how that could work out in an editor, the last thing you want is a confused user who edits someone's address following and ends up changing the address of many others. You end up abandoning the user2address table, and stick to a user_id field in the addresses (thus a 1-n relationship).
(Don't dismiss the example as silly, I've actually seen this in real life for company names and addresses on a system that had a contact2company table. A secretary changed a company's name and address because a contact had a new employer. This resulted in a near-dup entry in the companies, and incorrectly changed the mailing address of several other contacts).
Point is, there are cases where UI leads to amend the model, and vice-versa.
Another crucial point, which you haven't mentioned but which I think is equally if not more important, are business rule edge cases. In those, "always" actually means "usually", and "never" means "rarely".
For instance, I've seen stores whose orders tables were tied to a single product and two dates (order_date/cleared_date). I said good luck with that if you need an order with multiple products or if a chargeback or partial refund occurs.
answered May 25, 2011 at 9:01
It's better to create Mock up screens first, as it will give you an idea of the Actors and Use Cases. But the mock up screens should be just that, and later, you should be coding them again according to the dynamic logic you would want.
Next, you should proceed to develop a data model for your application. The ASP model should reflect that. Finally you can design your Controllers or Actions. Last come the screens or actual UI.
This should be per use case scenario. As you are one man army, you can create small use cases, as loosely coupled from others as possible.
Hope this helps.
--Sid
-
I understand the meaning of the view is the UI is that correct? minus any fancy formatting / css– MVCylonCommented May 24, 2011 at 19:42
-
1Yes, View is the UI in terms of MVC. Mock up screens can be anything from simple wire frames to HTML pages. You can have CSS done at the time of creating mock ups, that will save the work later, as CSS mostly will not change with any dynamism that you may introduce later.– SidCommented May 24, 2011 at 19:45
-
This is pretty much the approach I take as well. Very rough sketches of possible UI, then Model -> Controller -> View in that order. Commented May 24, 2011 at 20:09
-
+1 - sane approach. Add system wide iteration/incremental dev to this and you are golden. Commented May 25, 2011 at 10:01
In the long run, the only thing that matters is having the correct model to solve the real problem.
You can (and should) tinker with the views for ever to get things "just right". The model, however, contains precious information that you can't as easily tinker with.
Time spent getting the model right is time spent creating software of enduring value.
Well - it depends - but if you would like to utilized the scaffolding tool then you'll need to have your model first.
answered May 24, 2011 at 20:22
