Yet Another Coding Blog : architecture

MVVM – This might hurt a little…

Avi Pilosof — Fri, 13 Nov 2009 21:23:57 GMT

This is an attempt at a collaborative post; I’ll fill in more data if/when people make suggestions; please add comments on more problems and other/better solutions – I’ll add the links.

Overall, MVVM is very attractive – but all the screen casts I’ve seen avoid some confusing pitfalls that you’ll come up against in the real world. The landscape at the time of writing is a plethora of frameworks that attempt to solve similar problems; I expect the community will settle on a small number eventually, and certain patterns will emerge.

Until then, I hope this will help.

Overall

Some things that you take for granted will seem impossible to do in MVVM (without breaking the rules). Sometimes this is due to Silverlight missing WPF features, other times it has nothing to do with that. Most of these holes are pluggable in some sense, which is why…:

Using a Framework

I recommend you use a framework. You can write your own, but please consider that it needs to handle quite a few things in order to solve the various problems in this article.

I can’t recommend which framework to use because I have no experience with them, but I do recommend considering the problems below and finding out how each framework solves them. If the framework doesn’t have a “reference application”, stay away – you’re going to need one.

Here are a few that I know of:

PRISM2.0, which is from the MS Patters&Practices group.

SilverlightFX, by NikhilK. Does alot more than just MVVM; great samples/posts.

MVVM Light

Lots of others

Reacting to a click

Scenario: User clicks button; you want something to happen.

Problem: You’re “not allowed” to use the codebehind and an event-handler, so it needs to be done in the ViewModel. However, the ViewModel is ignorant of the view, so it doesn’t know about the button’s existence – it can’t hook into the click event.

Solution: You need support for “commanding”. Put very simply, this is usually a broadcast/listen mechanism where a “command” gets raised by someone, and someone else chooses to listen to it. In this case, the button would raise a command, and the ViewModel would be listening for it, and act.

WPF has it built-in, Silverlight does not – but the various frameworks have tacked it on, and it’s a basic pillar of MVVM.

Opening a dialog

Scenario: You have a listbox, the user double-clicks on an element, and you want an edit dialog to pop up with that element’s data to be edited.

Problem: You’re not allowed to have logic in your code-behind, so you can’t simply react to the event there. So you raise a command, and the ViewModel listens to it… But it’s not allowed to reference a UI component such as a dialog!

Solution: Much as above, you use the broadcast/listen pattern… However, instead of having the ViewModel listen, you have some central app “router” listening, and it knows how to open a dialog.

Passing a value to a dialog

Scenario: Same as above.

Problem: You’ve raised the command, and it knows to open a dialog – but how does it know to pass in the currently selected item from the listbox?

Solution 1: Perhaps your framework allows that item to be set as the command argument as part of the XAML. If so, perfect. If not (or if you need something more complex):

Solution 2: Raise the command, but have the ViewModel listen to it instead of a central “router”. The ViewModel figures out what needs to be passed in (for example, a “CurrentlySelected” bound property on itself), and raises an appropriate command.

Closing a dialog

Scenario: You opened the dialog, the user made their edits and clicked “Save”, then the dialog’s ViewModel called the web service to save the changes. Now the dialog should be closed.

Problem: The last bit of code that ran was on the dialog’s ViewModel; it can’t tell the dialog to close because it has no notion on the dialog’s existence…

Solution 1: Some frameworks have built-in support for dialogs and will handle this.

Solution 2: Cheat; if you’re not a purist, try this: The ViewModel raises an event (“TimeToClose”) with an argument of success/failure. The View’s codebehind subscribes, and closes the view itself.

Animations

Scenario: Your app shows a list of servers, and their status is all “good”. The ViewModel loads some new data, and one of the server’s changes to “bad”. The UI needs to react by playing an animation for that server.

Problem: Fundamentally, you don’t want your ViewModel to know anything about animations, storyboards, VisualStates, etc. It changed the data, but all we have on the view side of things is how to display the data; what we really want is the ability to trigger a storyboard, or to bind an element from the ViewModel to a VisualState on a framework element.

Solution 1: You can try to cheat here by using the codebehind, but depending on your exact scenario it might not help at all.

Solution 2: This article seems to do a good job of replicating DataTrigger for Silverlight (although I’ve yet to experiment with this):

http://blois.us/blog/2009/04/datatrigger-bindings-on-non.html

Avi

Be Paranoid. Be Very Paranoid.

Avi Pilosof — Wed, 03 Dec 2008 06:29:33 GMT

Do you maintain an application with a backend database? Does that application ever write to the database? Be afraid.

The worst situation to be in with respect to the above is when a customer mails you and says: “Why is my data gone?”

99% of the time, it’s because they clicked on the “Delete” button; but sometimes you need proof – this is what I want to discuss.

Log every interesting write to the database. There are various levels at which you can do this:

Application logic level: This gives you the most context, the most usable logs, and in fact gives you data which can generally be exposed directly to the customer, preventing lots of questions. The problem is that it’s not reliable: The app could succeed in writing then fail in logging. Alternatively, a dev on the app might forget to add logging to a new feature.
Application object model level: A little less context/readability than above, a little more reliability.
Data-Access-Layer level: Less context than above, more reliability.
Sproc level: Same tradeoff.
Table level (triggers): And same again.

As you can see, the lower you go, the less chance for error and the less value a log entry gives you. You can increase the value of a “deep” log entry by forcing a set of arguments up the stack. For example, you can force every sproc which writes data to require username/machine/reason arguments – but this can become costly to maintain.

So which is right? Depends on your app, your level of paranoia, your customer’s needs, etc. Generally I stay away from triggers and try to add logging at the sproc level for critical sprocs, and at the app/OM level for extra context; better to have too much logging than too little.

Here’s a nice trick for creating a footprint log table that your sprocs (or triggers) can use quite easily - Create a simple table with the following columns (at least):

Name	Default value	Comment
LogEntry		The text you want to log.
TimeStamp	getdate()	Automatically fills in the current datetime.
User	system_user	Automatically inserts the logged in user’s ID.
Machine	host_name()	Automatically inserts the user’s client machine name.
Application	app_name()	Automatically inserts the name of the application running this code (provided you set it in the connection string, which you should!)

Inserting into this table requires only the one column, but you capture lots of extra data for free. If this is done from a trigger, then you’ll even catch slackers with access to the DB who are updating it manually.

Oh, don’t forget to age off old entries before the table ends up at 50GB ;)

Avi

On using Arrays

Avi Pilosof — Tue, 23 Sep 2008 03:52:32 GMT

Eric Lippert has a great article on arrays:

http://blogs.msdn.com/ericlippert/archive/2008/09/22/arrays-considered-somewhat-harmful.aspx

I think this is especially useful to consider if you’re writing an API. Consider not just arrays, but any time you’re returning any collection: Are you returning values or a variables? Did you mean to?

Avi

Creating Testable Applications Using the MVP Pattern

Avi Pilosof — Sat, 02 Aug 2008 21:23:51 GMT

(The following post talks about ASP.NET, but it actually applies to all UI-based applications, web and non-web. PHP, WPF, Winforms, etc. It does not require a framework, nor anything to install - it's just an interesting way to write your code such that it has a clear separation of concerns).

The Problem

Your typical ASP.NET application is difficult to test, because much of the logic is contained within the codebehind files, which derive from Web.UI.Page, which needs an HttpContext, which is difficult to mock. Furthermore, the output of the methods in the codebehind is often not easily-testable, because it's a side-effect (such as calling DataBind() on a GridView).

This same problem exists in most UI frameworks: How do you test the logic used to generate a UI without having to take heavy dependencies on that UI's implementation (thereby complicating the tests immensely)?

The Goal

Ideally, you'd be able to take all the logic you want to test and put it outside of the UI framework (ie; the ASPX codebehind), such that you can test that logic separately without depending on that UI framework. You want your logic to be able to update the UI, but at the same time need to know as little as possible about the internals of that UI.

Achieving the Separation Using the Model-View-Presenter Pattern

The Model-View-Presenter (MVP) pattern separates your app into three parts:

The Model: This is the same object model that you currently use for your business objects, data objects, whatever. This remains unchanged.
The View: This is your ASPX file; but it's as thin and dumb as possible. By that I mean that it only renders data that has been given to it; it doesn't do any thinking about what data it should have and where to get it.
The Presenter: This is the brains of the operation. The View asks it to act on the user's desires; it consults the model, then tells the view what to render (although not how to render it - that's the key part!).

The key to all this is that the Presenter avoids having a dependency on the View by having all the View's data requirements defined in an interface, and creating the dependency on that interface instead of on the view. That can then easily be mocked up for testing.

All this is best presented as a before/after example. Here's the scenario: We have a page that needs to display a list of people, filtered by a user-defined string. In order to do this, it eventually needs to bind a list of people to a GridView, which will take care of the rendering.

The "Before" Code for handling the user's button press to filter the list:

In PeopleView.aspx.cs:

   1: void btnFilter_Click(object sender, EventArgs e)

   2: {

   3:     ShowSomePeople(txtFilter.Text);

   4: }

5:

   6: private void ShowSomePeople(string filter)

   7: {

   8:     List<Person> lst = LoadAllFromDB().Where(p => p.Name.Contains(filter)).ToList();

   9:     gvwPeople.DataSource = lst;

  10:     gvwPeople.DataBind();

  11: }

(Here, the LoadallFromDB() call is a call to the Model to get a list of all Person objects from the DB).

The "After" Code:

First we create the interface definition which defines what data our View needs in order to render the page. We know it needs the actual list of people to show, and maybe an error message in case of problems. So, in PeopleInterface.cs:

   1: public interface IPeopleInterface

   2: {

   3:     // The list of people to show

   4:     List<Person> Members { get; set; }

5:

   6:     // Show this if something went wrong

   7:     string Error { get; set; }

   8: }

In PeopleView.aspx.cs (the codebehind), we implement this interface:

 
   1: public partial class PeopleView : System.Web.UI.Page, IPeopleInterface

   2: {

   3:  // ...

   4: }

5:

Then we update ShowSomePeople to call into the Presenter, instead of doing its own thinking:

   1: private void ShowSomePeople(string filter)

   2: {

   3:     PeoplePresenter Presenter = new PeoplePresenter(this);

   4:     Presenter.LoadWithFilter(filter);

   5:     gvwPeople.DataSource = this.Members;

   6:     gvwPeople.DataBind();

   7: }

Finally the Presenter itself, in PeoplePresenter.cs (a standalone class):

   1: public PeoplePresenter(IPeopleInterface v)

   2: {

   3:     View = v;    // "View" is a private member

   4: }

5:

   6: public void LoadWithFilter(string filter)

   7: {

   8:     // Tell the view what data it should be showing

   9:     View.Members = this.LoadAllFromDB().Where(p => p.Name.Contains(filter)).ToList();

  10: }

The interface defines the "contract" between the View and the Presenter, allowing the Presenter to be agnostic of the guts of the View. In theory if you wanted to add a WPF client for this application, you would not need to touch the Model or the Presenter or your unit tests - you would just implement a WPF view that adhered to the same interface.

It may look like much more code, but note that it's just a couple of tiny classes per page; this overhead is fixed and doesn't grow with the complexity of your ASPX page.

Unit Testing

Because you've made your view "dumb" (it mostly just databinds), all your business logic exists in the Presenter and Model, meaning that you probably don't need to test the View. In order to test the Presenter, all you need to do is pass it a mocked up implementation of the interface that it asks for. So:

Create a mock that implements the interface (example).
Pass that into a new Presenter.
Run the Presenter methods.
Check the properties of the mocked object to see that the Presenter set them correctly.

What about MVC?

As Scott Guthrie has mentioned, MVC is not the new recommended method of building ASP.NET apps; it's just another method. I love the simplicity of the MVC framework, but my team has invested in server controls that are incompatible with it, making it too costly to move to at this point.

MVP gives us similar benefits (testability), without the cost of re-wiring our controls, and with pretty much no learning curve.

Notes:

Microsoft's Web Client Software Factory gives you templates for project creation which implement this pattern for ASP.NET.
If you want a comprehensive comparison and history of MVC, MVP and related patterns, see this article.

Avi

It's all just a clock measuring contest...

Avi Pilosof — Fri, 04 Jul 2008 01:13:00 GMT

Did you know that SBCL is now faster than Java, as fast as Ocaml, and getting better?! What does this mean for you? Most likely, nothing.

They have various benchmarks that are used to measure the speed of a language implementation; and I think it's a good thing - it keeps the implementers honest, and I'm not crazy about wasting CPU cycles just because they're there.

However, these numbers remind me very strongly of the local CompuMart selling the 2.4GHz machine for 1.5x the price of the 2.0GHz machine and relying on the fact that customers have no idea that this will make exactly zero difference for most uses.

Why? Because pretty much all programs nowadays depend on more than just the CPU. They're competing for RAM, disk access and maybe even network. None of those are nearly as fast as the CPU, hence most often create a bottleneck.

Aside from this, it's very likely that the code you're writing will be more dramatically improved by tweaking your algorithms than it would by changing the language.

Couple that with the unfortunate fact that most jobs won't allow you to just grab SBCL or OCaml because it happens to be at the top of the list today, and you're left with a measurement that has little real-world value.

What these measurements are good for is preventing those who write the language implementations from getting too lazy. While I think that application programmers should generally be spending CPU cycles to save lines of code, I don't necessarily believe the same for platform/language programmers.

Just don't look at this list and get too disheartened about your choice of language. Even if it is Ruby ;)

Avi

Can Software be Reliable?

Avi Pilosof — Fri, 27 Jun 2008 09:21:29 GMT

Just read a post (permalink is broken) regarding how software engineering is nowhere near the level of quality as traditional engineering, partially because we don't have standards, regulations, etc.

While I agree with some of the argument, people often give too much credit to meatspace engineering when compared to software.

You often get what you pay for, and this applies to both types of engineering. Look at NASA's software engineering team (awesome article). Two quotes from there:

"The last three versions of the program - each 420,000 lines long - had just one error each. The last 11 versions of this software had a total of 17 errors. Commercial programs of equivalent complexity would have 5,000 errors."

And:

"...the group's $35 million per year budget is a trivial slice of the NASA pie, but on a dollars-per-line basis, it makes the group among the nation's most expensive software organizations."

Similarly, there's other very reliable software running very reliable systems (nuclear reactors, chemical factories, fighter jets, stock markets, whatever). Basically, when you're prepared to pay for software quality, you can get it.

Viewing things from the opposite direction; while it's true that none of my cars have ever spontaneously combusted on the highway, neither have any of them been bug free. There are always rattles, electrical problems, mechanical problems, and they all need constant maintenance - I can't treat my car recklessly and expect it to behave well forever. Just like with software, environmental changes can bring out defects in the original design. Bridges need constant maintenance, cracks form in buildings, roofs leak, gutters rust, foundations sink, water rises, dishwashers break (taking down my whole circuit) and light bulbs fry themselves.

Most of these things can be avoided with the judicious application of more resources (read: money [=time]). It just happens that most software companies get a better return on investment spending that money on new features/products than they do on aiming for five nines. Why? Because that's generally what customers respond to. What would you prefer - an iPhone with Safari occasionally crashing, or that small Ericsson from 1997 that never ever crashed?.

Sometimes it makes sense to spend a fortune to get that extra 1% (10%?) of quality, but each percent costs more than the last. I certainly want that last percent on bridges, airplanes and skyscrapers. But if I had to pay 3x the price for my video card (or phone, or DVD player) and wait 3x as long for new versions, I don't think it would be worth it.

Avi

On Writing Safer APIs

Avi Pilosof — Thu, 19 Jun 2008 05:08:57 GMT

Our team owns lots of smallish applications; all of them have a DB layer, an OM/API layer, logic and UI layers. What happens over time is that we have different people working on the same apps, switching between them over the course of time.

This is great for cross-training, for support, for finding missed bugs, for preventing boredom-induced suicides, etc. However, the price you pay is losing that intense expert focus that someone gets from living+breathing a single app for years. That can lead to a few more bugs.

I've noticed that at the core of many of these bugs is the OM/API layer, and I wanted to summarize some issues I've seen and some suggested fixes. I'd also love to hear any other pointers you guys have.

Problem 1: Database call abuse.

We take great pride in squeezing the most out of our database servers. One of the primary ways to do this is to hand-code your DB access via sprocs and ensure that they return multiple result sets where possible. So for example, if I know that the main build status page needs to show builds and their comments and their last 15 status events, then I'll make sure that one sproc call returns all of those for all the builds - optimize for reducing the number of DB round trips. BTW, you can do this with LINQ-to-SQL.

However, this generally conflicts with writing a "neat" OM which performs simple concise tasks; and is often people's resistance to using ORMs. You need to learn how to balance the two.

Invariably, you'll eventually realize that some page is relying on some call which relies on a deep OM call which makes a sproc call. But that parent page makes the call 300 times; one for each item... Ouch.

Some solutions:

ABP: Always Be Profiling. This simple and brilliant idea comes courtesy of my teammates Jason and Karthik. Basically, as you're fixing bugs on an app, have the SQL Profiler running on your 2nd monitor and watch out for crazy spikes in traffic coming from your app.

Caching: When possible/applicable, cache the results of your DB calls at the lowest level that makes sense. You can cache for the whole lifetime of the app, for the session, for the context, or using a custom caching policy with the caching object. The point is; ask yourself whether you really need to read that stuff from the DB.

Commenting: One of my favourite VS features is that the "/// <summary>" comments show up as intellisense hints. This means that as your API consumer (your team-mate!) is using the method call, they get free documentation. So, if the method being called doesn't cache, call it out. It'll cost you 20 seconds:

   1: /// <summary>

   2: /// Get the comments for a build.

   3: /// NO CACHING - this always makes a DB call.

   4: /// </summary>

Problem 2: Units of measurement

This might seem obvious/stupid, but I bet it happens to the best of us. Take a look at this call:

   1: int BuildSize = build.Size;

"Size", eh? Bytes? Megabytes? Gigabytes?

Some solutions:

Naming: If you suffix your properties/methods with the units they return, this is unlikely to happen. SizeInBytes, SizeInGB, etc. Really cheap.

Typing: Rather than Size being of type int, have it be of type "Gigabyte", which you can create yourself. The type system will then ensure you don't make silly mistakes. This can be a little more costly if you do it pervasively, but it's quite powerful and allows for centralizing your unit conversions (are there 1000 MB in a GB, or 1024?).

Commenting: Again with the summary comments. Check it out:

   1: /// <summary>

   2: /// Get the size of the build, in BYTES.

   3: /// </summary>

So cheap.

Problem 3: Discoverability

I'm new to this application and I want to find the size of the build. My instinct is to look for build.Size (sorry, SizeInGB! :)), but I don't see it. So I go off and write it, to later find out that there already was a build.GetSize().

Some suggestions:

Properties vs. Methods: Some people would deliberately use the GetSize() method rather than the Size property if determining the size required some "work" (DB call, expensive calc), to indicate to the caller not to take this call too lightly. Personally, I think it's confusing. I think that if something is a logical property, then it should be declared as a property; methods are for "doing stuff"; although sometimes that's a gray area. Whatever you choose, ensure that you're consistent across your app(s) when doing this.

Smaller classes: Often easier said than done, but a class with 30-40 methods and 20 properties is going to have discoverability problems, not to mention other issues. Break it up into smaller classes or helper classes where possible. Read this.

Design the API: Often, the API just "happens" as a result of writing the application; don't pretend you haven't done it! I think that designing the API up front with a view to having it used by other people makes for a much better, more well rounded API that has more discoverable avenues for success and needs less documentation.

Pretty files: This goes in the "Commenting" bucket. Use regions to separate your class file into logical parts. Put all the properties together in one place; put all related methods close to each other. Ensure that methods are named similarly when they do similar things.

If there are suggestions for other solutions (or other problems), please contribute; I've got lots to learn.

Avi