MVC Issue Tracker: Where We've Been

I should have the final code zipped and pushed to CodePlex as a download sometime today or tomorrow.  This post is sort of a retrospective on what we've already done.

If you missed the posts, here they are in order
Introduction
Part 1- Setting Up
Part 2- Controllers
Part 2.5- Ancillary Issues
Part 3- Cleaning Up the Views
Part 4- Finishing Up

So, some impressions to wrap up:

First off, while I would have liked to implement my own authorization system, MVC3's provided version met all my needs quite well, and so there was no reason to handle that.  So that got cut out at the end.  I do like the fact that, for almost all scenarios, the MVC3 provided authorization model works well enough.  Perhaps someone with exceptionally high security needs would be required to create their own model, but I doubt anyone with such needs would be using MVC (the product) anyway.

Which leads me to my second point.  ASP.NET MVC3 seems to me like something a small company (even big for a small company, but small nonetheless) would use to get a website up and running relatively quickly.  I can see that it has plenty of power for the mid-sized business as well, but once you get up to larger enterprises, I see things I believe would cause some problems.

First, I don't like the lack of separation of the code.  MVC3, by default at least, throws all your code into one project.  I believe that my Model code (let's face it, it's the Data Layer) should be in a separate project, at least, and possibly a separate solution.  The Controller code- being the Business Layer- should, to my mind, be likewise separated- either in a separate project or separate solution.

Now, I don't see any reason you couldn't use MVC like methodology and still have those layers of separation, but MVC3, in itself, is fairly dependent upon having all that code in the same project- at the very least for auto-generating views and controllers.  I may be wrong, but it seemed to me that MVC was built on the idea that all of this code would be in the same project.  That's fine for fairly small and/or encapsulated applications, but a larger enterprise with multiple web applications may very well have need to separate those layers better simply because they want people to interact very differently (beyond simple authorization issues) with the same data.

Take, for instance, the sample project the good folks at MS use of Contoso University.  Their MVC3 tutorial walks you through setting up a way to enroll students, or add classes, or whatnot.  In a real life situation, that enrollment, and most of the administrative functions, would be handled (if they used MS Technologies at all) on an internal only application- whether an intranet application or a windows application- and all anyone logging in would be able to do is some basic maintenance of their own student account and request enrollment (with the actual enrollment being handled by some other application to ensure class sizes were set properly, etc.).  This would lead to it making more sense to have that level of separation.

Now, my thought is that MS would be saying, "You're right- so you don't use MVC for that."  That's a completely reasonable expectation- but it is something to be aware of.

All in all, however, I was impressed by the power of MVC and the ease with which the application came together.  Certainly it would need a lot of cleaning and polishing before anyone used it as an actual production application, but I can see the seeds in there for just such a thing.  Add to that the lightweight nature of the newest version of SQL Compact for the database, and a small company could easily use such a thing- instead of some big and expensive tracking system- to track their trouble tickets.  And, as with anything that contacts the database, all that really needs to happen if the ticket database grows too big is to create the same db schema in some more robust database (say, full on SQL Server, or whatever) and change the web.config connection string.

I hope this exploration has been as beneficial for you as it was for me.