Working With ASP.NET MVC
Since the release of ASP.NET MVC I think the whole world has suddenly realised that the Microsoft team are actually doing something good, despite taking years to catch up with other MVC frameworks such as the Zend Framework. The good thing is that I’ve been keeping a close eye on what the team have been doing, and despite my knowledge not being great in the area I’ve noticed that throughout Scott Gutherie’s blog the decisions made do seem to be very good.
When I first started with ASP.NET I thought it was a nightmare, the fact that you had “web controls” which required forms on the page with runat=”server” attributed on all HTML elements. I hated this. I started off in the company I currently work for wondering what on earth we were using, but the fact was that ASP.NET had evolved into “web forms”. There are many reasons I don’t like it especially with the ViewState property being enabled by default on all controls meaning if you check the response from the server when a web page is generated you’ll notice a load of encoded data sat near the header. On some of the pages we worked on the ViewState drowned out the actual HTML completely.
ASP.NET MVC gets rid of all of this. No more ViewState, less use of forms et cetera. As lovely as it is though the majority of guides, articles or tutorials simply don’t cover large-scale applications. Our applications are gigantic, some of them I’ve never had to deal with and simply wouldn’t be able to by myself because they’re so large. Applications as large as this need testing which is one of the major points of MVC. So, here’s some problems with ASP.NET MVC that I have.
Nested Controllers, Views and Models
So imagine your application is simply so large that you have roughly one hundred folders and some of which go to about five to six levels deep. This is done to separate out area of the application. The application is one major application made up of many smaller applications essentially. Should you create separate projects for each which are somehow controlled from a single web application, or combine the lot? Is we combine all of them, how do we deal with nested folders? ASP.NET MVC deals with controllers, views and models on a folder by folder basis. So our mapped routes looks like {controller}/{action}/{id} but if we have folder structures such as myapp/mysubapp/adeeperfolder/thepageaction/theid then things start to get tricky, especially if this happens time and time again. Haacked covers area in MVC, but again, this may not cover all cases especially for those of a gigantic application. There are custom routes available to work with, but how many would we need? Quite a lot to be honest.
So what’s the solution? Well, if we had a URL such as app/myapp/mysubapp/myaction/param then could we not take everything before myaction/param and map it automatically as the path to the controller? I believe this actually breaks the separation of MVC, but for us it seems the most logical approach. I do ponder on this.
No More Controls!
Okay, whilst beforehand I would’ve cursed at controls they do aid in speedy development. So what now? We have to manually create reports in the view. I’m not saying I have a problem with this, but as my boss said, this moves back to the “Active Server Pages” days. We’re so used to saying “yes we can provide this report, and it’ll only take us two minutes to do”. It may not be the right way, but it produces a result which someone may need right now.
The idea is that every view represents just that, a different view of something. If you’re editing results returned into a table then the “edit” button would take you to a different view. Are you supposed to be able to edit within the table i.e. turn the row into a row filled with textboxes that you can edit, then have an update button the same row? I’m guessing now. But this does mean that the amount of views and associated controllers increases substantially. If you have thousands upon thousands of pages already, surely they will multiply?
No Going Back
The other major concern is that it’s simply such a big step that it’s a case of “out with the old and in with the new”. You can’t mix and match, and you couldn’t move back again. It’s just too big of a job, and required too many man hours. The amount of time already that I’ve spent in investigating, gathering requirements, and solving problems is already too great to be throwing the idea out altogether.
XSLT?
Seeing as though we no longer have controls what happens with things that we commonly use such as XSLT for generating complex pages? Has that died a horrible death altogether? Again, I’d love to know.
Data Access
The major issue I’m really having is accessing data correctly. Seeing as though I have no prior experience I’ve realised it’s extremely important to have a data access layer, but there are many tools available such as LINQ. LINQ won’t do what we want because it’s slower than other technologies and we’d simply only use it for stored procedures. Simply, strongly-typed stored procedures are required. Also the ability to insert/update/delete based on exposed functions through objects. Again, with such a complex schema this isn’t a simple task.
I’m not sure what everyone else’s opinion is on the use of ASP.NET MVC but those are just a few of the issues I’ve run into so far.