Model is one of those overloaded words in software. Just saying the word model can produce a wide range of expectations depending on the context of the conversation. There are software process models, business process models, maturity models, domain models, security models, life cycle models – the list goes on an on. Nerds love abstractions, so it’s not surprising that we have so many models to choose from.
Let’s talk about a specific model – the model in model-view-controller. What is it? How do you build one? These are the types of questions a developer will ask when working with the ASP.NET MVC framework. As Simone Tokumine points out in his post “.NET MVC vs Ruby on Rails”, there isn’t any direct and specific guidance from Microsoft:
.NET MVC is actually .NET VC. It is an attempt to replicate the Actionpack components of Rails. There is nothing included aside from a folder labeled “Models” to help you with your persistence later and domain modeling.
The scenario isn’t unique to the MVC framework. Microsoft has a long history of leaving the model of an application open to interpretation, and this stance is both a blessing and a curse. A blessing because we can build models to meet the distinctive needs of every application imaginable, and we can use a variety of tools, frameworks, patterns, and methodologies to build those models. However, the curse is that many of us never look outside of the System.Data namespace. Populated DataSets and data readers are the models in many applications, even when they aren’t the best fit.
One reason that DataSets dominate .NET development is because they are featured in the majority of samples and documentation, particularly for ASP.NET Web Forms. In contrast, ASP.NET MVC samples typically feature business objects as models. Even the new MSDN documentation says:
Model objects are the parts of the application that implement the domain logic, also known as business logic.
It’s not surprising then, to see many people using domain objects, business objects, and entities produced by LINQ to SQL or the Entity Framework as model objects.
Do business objects and entities really make the best models?
This is the question I'd like to explore by sharing my opinion and gathering feedback over the course of two more blog posts...
The ASP.NET Connection show in Orlando was a fantastic event. Thanks to everyone who came to a session. Here are the slides and demos for everyone who asked for them.
In the last half of this session we re-factored a dashboard type application with an eye towards using properly abstracted JavaScript code. The dashboard page was loosely based on the code from my Extreme ASP.NET column in the March MSDN Magazine: Charting with ASP.NET and LINQ.
Part of the refactoring process was removing all signs of JavaScript from the .aspx file to achieve the separation of behavior and markup that defines “unobtrusive JavaScript”. If you give JavaScript the focus it deserves, it can love you back.
Other links:
Advanced LINQ Queries and OptimizationsLINQ is inherently more about productivity and expressiveness than performance. We talked about how to avoid unnecessary performance penalties with LINQ, some non-obvious optimizations, and the first optimization you should make - optimizing for readability.
Other links:
A little Blend, a little XAML, a little Visual Studio.
Links:
JavaScript has made some improvements in its “state of the art” over the last several years, despite your best attempts to ignore the language.
Yes, you.
The language hasn’t changed, but the tools, practices, runtimes, and general body of knowledge have all grown and matured. Yes, it’s still a dynamic language, and we all know that you think dynamic languages are more dangerous than a loaded gun, but you can’t ignore the language any longer. JavaScript is everywhere. Why, just the other day I turned on “Who Wants To Be A Millionaire?”, and what did I see?
Here are some signs that you might be behind the times.
1. If you still mix JavaScript and markup …
<head> <script type="text/javascript"> function doStuff() { alert("boo"); } </script> </head> <html> <body onload="doStuff();"> ... </body> </html>
… you should read up about unobtrusive JavaScript. In addition to the performance benefits of keeping script in a .js file that a browser can cache, you also separate your presentation concerns from script behavior and allow yourself to focus on writing better script.
2. If you still use document.getElementById and assign functions to onclick …
var header = document.getElementById("header"); header.onclick = headerClick;
… then you really need to start using one or more JavaScript libraries. There are many great libraries available – just look around. They help isolate you from variations in the browser environments, increase your productivity, and allow you to write more maintainable code.
Other obsolete patterns:
3. Using document.all or document.write
4. Using global variables and global functions
5. Rolling your own browser detection code
6. Debugging with alert messages
Once you learn modern JavaScript idioms and tools, you’ll never look back at these old anti-patterns.
A friend recently had to replace some electrical outlets in her house because they stopped functioning. There was so much corrosion built up between the aluminum wiring and the outlet contacts that the outlets quit working (which is much better than the alternative - catching on fire). 
Did you say aluminum wiring?
During the classic rock era of the 1960s and 70s, aluminum wiring became a popular replacement for copper wiring in the USA. Due to a copper shortage, aluminum was cheaper than copper and allowed electrical contractors to lower construction costs. I was quite shocked to hear about aluminum wiring in her home, I’ve only seen copper myself, but according to the CPSC there were ~2 million homes with aluminum wiring by 1974.
Over the years, a number of problems with aluminum began to surface. Aluminum wiring is more brittle than copper, and much more likely to oxidize, corrode, and overheat. Aluminum wiring just isn’t as safe as copper wiring* and is now banned in the electrical codes of many jurisdictions. Aluminum wiring lives on in many houses, however, because it’s expensive to swap out a piece of embedded infrastructure like wiring.
Engineering is always about tradeoffs. But many times we start using a technology, tool, or methodology because it appears to save us time or money. It’s only later that we can see the problems clearly.
My question for you is:
What do you think is the “aluminum wiring” inside today’s software? What have we adopted recently that we’ll look back on in 3 years and say “ouch”.
Here are a few candidates to start the conversation (based on an informal poll of random developers I accosted):
* If you are replacing outlets with aluminum wiring coming in, please, please, please be sure to use an outlet made for aluminum. They are more expensive, and the young clerk at the store will try to sell you an outlet for copper wire, which can be a fire hazard.
When my jQuery code doesn’t work, it usually means I’ve done something terribly wrong with my selectors. Thus, my first rule of debugging code that uses jQuery:
Make sure the selector is actually selecting what you want selected.
I can liberally apply rule number one before fiddling with event handlers and method calls that come later, because it’s easy to do and saves me time.
Step 1: Navigate to the page with a problem and open FireBug.*
Step 2: Type your opening selector in the command bar of the console.
Step 3: Verify the object length is > 0
If you need to take a look at the objects you’ve selected, then a little console logging inside FireBug goes a long way.
$("div > a").each(function() { console.log($(this).text()) })
I hope this tip saves you as much time as it has saved me!
* Technically, any JavaScript execution environment will work, like the Visual Studio immediate window, but the FireBug / Firefox combination is simple and works every time. Another one I like is the jsenv bookmarklet from squarefree.com.
Spark is a view engine for the ASP.NET MVC and Castle Monorail frameworks. I’ve been wanting to try this creation by Louis DeJardin for some time, but ScottW pushed me over the edge with “If you are using ASP.Net MVC, you owe yourself to spend some time with Spark”. The Spark documentation makes it easy to get started, and the source code and examples are even more valuable.
There are quiet a few tutorials for Spark floating around, but I wanted to call out what appears to be a well hidden secret in the samples: the client rendering of views. In short, the client rendering produces JavaScript you can invoke on the client to render the same HTML you see when rendering a server-side partial view. This means you can happily fetch JSON from the server and use it to produce HTML without duplicating the server-side template logic on the client.
As an example,let’s say you have the following partial view to render the employees inside a department:
<div id="employees"> <table> <tr> <td>ID</td> <td>Name</td> </tr> <viewdata department="Models.Department"/> <tr each="var employee in department.Employees"> <td align="right"> ${employee.ID} </td> <td>${employee.Name}</td> </tr> </table> </div>
Notice how in Spark you can weave C# into the markup without breaking the flow of the HTML.
Next, let’s say you wanted the ability to refresh just this partial section of your view by asynchronously fetching data from the server. A first step would be to create a controller action that returns a Spark JavascriptViewResult.
public ActionResult ShowEmployees() { return new JavascriptViewResult {ViewName = "_ShowEmployees"}; }
This action tells Spark to generate some JavaScript code from the _ShowEmployees partial view (the one we see above). The JavaScript will know how to create the same HTML as the server side view. Since this action produces JavaScript, you'll want to add a <script> in your main view that references that action endpoint. (this is reminiscent of how ASP.NET AJAX produces WCF proxies in JavaScript that know how to invoke service endpoints on the server, except client rendering isn’t about services – it’s about sharing a data binding template logic between the client and server).
<content:head>
...
<script type="text/javascript" src="~/Department/ShowEmployees"></script>
</content:head>
What you’ll receive in your view is a JavaScript object with a RenderView method, and the RenderView method knows how to take your view model (as JSON data) and create the same HTML as the server-side partial view. Combining this generated JavaScript object with jQuery’s AJAX capabilities is straightforward.
$.getJSON( "/Department/Refresh/" + $("#id").val(), function(data) { var content = Spark.Department._ShowEmployees.RenderView( { department: data }); $("#employees").html(content); });
The above code gets a JSONified version of your view model from the server and passes it into RenderView. RenderView returns the HTML we can use to update the UI. Clever!
For more on Spark, check out Lou’s blog.
Phil and Scott (and the other Scott) announced the open source Nerddinner.com project and their free ASP.NET MVC eBook today. Actually, the free eBook is a single chapter of 185 pages, which is at least 50 pages longer than any chapter in Tolstoy’s War and Peace (and over half the size of my entire workflow book). Amazing.
In any case, I was looking through the code this evening and a thought struck me. You can divide the nascent world of ASP.NET MVC developers into two camps:
The people who use strings don’t love to use strings – they just use them to get work done. But the people who hate strings really hate strings. They’d rather be caught using goto label than ever type a string literal, and they exterminate string literals from as many places as possible.
The views in Nerddinner.com are full of strings:
<p> <label for="Title">Dinner Title:</label> <%= Html.TextBox("Title", Model.Dinner.Title) %> <%= Html.ValidationMessage("Title", "*") %> </p>
The “Title” string is significant – it has to match up with the name of a controller parameter or the name of a model property when data movies in and out of the controller. A typo in the view, or in a model, can create bugs. Compare the “stringy” views to the views in another open source MVC application - CodeCampServer:
<%=Html.Input(a => a.AttendeeID)%> <%=Html.Input(a => a.ConferenceID)%>
This is another example of using LINQ expressions to implement “reflection without strings”. A typo here yields a compiler error. The technique is quite powerful and implementations are popping up everywhere, including inside the MVCContrib project.
Errors can be caught with either approach, but you can catch errors earlier and perform safer refactorings if you take Nancy Regan’s advice and Just Say No (to magic strings).
I’m curious – which approach do YOU prefer?
