A recent undertaking of mine involves a paradigm move into a different framework. My traditional approached, in the IIS/ASP environment, has been to use ASP.NET rendering with the traditional HTML/C#.NET or VB.NET code-behind. Instead, I have a project that is based on MVC, or more specifically, Microsoft's MVC framework in ASP.NET.
MVC is an acronym for Model-View-Controller. This paradigm is a class-centric view of the typical client-server model. For instance, in ASP.NET, the markup and code-behind draw a division that is hardware-centric. The concept of MVC is scalable - it can be applied to an individual control as well as an entire interface. In this overall concept, the Controller receives the requests from external actors and interprets those requests as modifications to the data (Model) or the View or both. Applying this to a single textbox control gives the focus/blur and keyboard handler to the controller; the text buffer is the model, with the size and other rendering delegated to the view.
Microsoft's MVC is not so conceptual. It is a specific implementation of the MVC concept to web renderings at the client-server level. In this case, a web site may contain a series of models. The input marshalling to these controllers is controlled through a router, which is largely hidden. The router operates on a subscription basis, which is in contrast to the discovery protocols used with the network devices that bear the same name. The subscription is caused by the signature of methods within the controller.
Though the View can be rendered using ASP.NET controls, MVC also has a new rendering engine, called Razor. This engine allows the user to more fluidly mix markup, Javascript, and code-behind. There is a price for this: Microsoft gets to guess what it's currently parsing. In my short stint using Razor, I've come across two issues with rendering abnormalities. The first was parentheses pairs in the data were being interpreted as Javascript function calls. Replacing the parens with brackets fixed that. The other involves Razor's string sterilization. By default, Razor will strip all potential cross site scripting (XSS) threats from strings. This can be specifically overriden for a given control, but there is no partial whitelist/blacklist for it. Instead of the familiar asp: controls, Razor has a parade of helper methods for control rendering. It also makes substantial use of jQuery. Despite some quirky issues with bad guesses, Razor seems to allow a code structure that is more closely related to the Document Object Model (DOM).
This brings us to the Model. In its simplest form, the Model is just a class with properties and no methods - a struct. From this, you could construct a data access layer in the controller to manipulate the Model properties directly through a familiar SQLClient class. However, my particular project did not afford such familiarity; the original designers decided (did I mention that I inherited this project - well, I did) to use the acronym coupling of EF (Entity Framework) on ADO (ActiveX Data Object) using Linq for Entities, and this is the crux of this post. Instead of a very simple set of static methods in a class of their own to use as an API, I have spaghetti. Nicely frameworked spaghetti, but spaghetti none-the-less. The primary issue is the degree of overlap between the Entity Framework and the actual database. Changes must be accounted for on both sides, instead of just at the SQLCommand/Stored Procedure interface. Linq for Entities brings its own problems to the party, as well. It is possible, between MVC's use of lambda equations and Linq for Entities' obfuscation, to generate a SQL call that has no direct reference in the code.
Before this becomes a rant - avoid EF and Linq for Entities. They bring nothing new, other than obfuscation headaches. As for the rest of Microsoft's MVC on ASP.NET implementation - the jury is out. I'll see how this project progresses.
-- Steve
No comments:
Post a Comment