WebDevLog

2011 Conceptual Web Framework Utopia – Part 2, Testing

2012-01-08T03:37:00.000-08:00

This short series of posts represents a snapshot of my thinking at the end of 2011, in terms of how I would ideally produce web applications using the .NET platform. In this, part 2, I’m going to cover my current testing strategy and preferences.

For this post, the plan is:

1. General Testing

2. Endpoint Testing, using the Endpoint Testing Pattern

3. Database Testing with RavenDb

I won’t be talking about higher-level tests or BDD that drive the TDD. The only variable there is the frameworks, which are generally interchangeable.

General Testing

My unit tests need to be fast, and they need to be readable – no interacting with databases then. See the last section for that.

To make unit tests readable I treat them as high-importance code. This doesn’t mean I take any longer, it means I have three simple rules that I nearly always use:

1. Keep them short (3 lines is optimal, 7 means I don’t get to eat for the day)

2. Hide assertions inside extension methods that read well (just like the GOOS boys)

3. Wrap setup code in methods too

[Test]

public void Get_GivenIdForExistingBook_ShouldReturnViewModel_WithBooksDetails()

{

var book = GetRandomBookSimulatedToExist();

var viewModel = endpoint.Get(new UpdateBookLinkModel {Id = book.Id});

viewModel.ShouldHaveDetailsFor(book);

}

Above is an example of what I consider to be an ideal test.

Context Specifications

With the above preferences applied, most of the time there are just 3 - 5 line test methods that follow like a given, when then. Sometimes, though, it really makes sense to use a context specification.

[SetUp]

public void WhenRequestingABookReview_AndTheSystemContainsBooks_WithDifferentGenres()

    var retriever = MockRepository.GenerateMock<IBookRetriever>();

    var endpoint = new ViewEndpoint(retriever);

    book = BookTestingHelper.GetBook(rating: 4);

    retriever.Stub(r => r.GetById(book.Id)).Return(book);

    SetupBookForSameGenreIncludingReviewBook();

    retriever.Stub(r => r.GetReviewedBooks(book.Genre.Id)).Return(allBooksForSameGenre);

    viewModel = endpoint.Get(new ViewBookLinkModel { Id = book.Id });

[Test]

public void ViewModelShouldHaveBooksTitle()

    Assert.AreEqual(book.Title, viewModel.Title);

[Test]

public void ViewModelShouldHaveBooksGenreName()

    Assert.AreEqual(book.Genre.Name, viewModel.GenreName);

[Test]

public void ViewModelShouldHaveBooksRating()

    Assert.AreEqual(book.Rating, viewModel.Rating);

If you look at the full source code for this class you’ll see there are another 6 tests below it. I think in this case it was the most readable way to test.

When Do They Run?

Always - these are the general tests that form part of the main suite for giving immediate feedback about any regressions.

Endpoint Testing

In part 1 my diagram mentioned “Endpoint-specific models”. This includes link (usually called request), view, and input models. By having them specific to each endpoint, the models are tested as part of the endpoint tests and not alone. I refer to this mentallly as the endpoint testing pattern, but it is not an official term.

For example:

[Test]

public void Get_GivenIdForExistingBook_ShouldReturnViewModel_WithBooksDetails()

{

var book = GetRandomBookSimulatedToExist();

var viewModel = endpoint.Get(new UpdateBookLinkModel {Id = book.Id});

viewModel.ShouldHaveDetailsFor(book);

}

This test covers the endpoint and the models. There would be no additional tests for the models – they only exist to serve one action method on this endpoint so don’t need it.

Update Scenario

[Test]

public void Post_GivenUpdateModel_ShouldCreateDtoAndPassToBookUpdater()

    var model = new UpdateBookInputModel

                 Genre       = "genres/9",

                 BookStatus  = BookStatus.Reviewed,

                 Title       = "Updated title",

                 Id          = "books/444",

                 Rating      =  3,

                 Description_BigText = "Updated description",

};

    endpoint.Post(model);

    updater.ShouldHaveBeenCalledWithDtoMatching(model);

For these scenarios, a simple assertion is made that a service was called. Anything more involved than that is probably logic that doesn’t live there in an ideal world.

When Do They Run?

These will be ultra-fast tests that are part of the main suite of tests. Every time there is a change in code, these get run to check for regressions.

Database Testing With RavenDb

I’ve specifically name-dropped RavenDb because this is my utopia. In this world, we eat, sleep and breathe RavenDb for data access because it makes life a lot easier. You get all the benefits of NHibernate’s session, transactions & POCOs, without any of the pain of the SQL mapping or performance disasters.

Another benefit of RavenDb is the testing support. In fact, this is fantastic. A mini Ayende sits their inside your pc spinning up an instance of his document database in your computer’s memory. As far as I’m aware, this works exactly the same as a normal instance of the database. None of those SQL Lite – SQL Server mismatches.

Here’s a data access test:

[Test]

public void GetWishlistBooks_ShouldOnlyReturnBooks_OnTheWishlist()

    PopulateSessionWithBooksOfDifferentStatus();

    Session.SaveChanges();

    var fromSession = Session.Query<Book>().Where(b => b.Status == BookStatus.Wishlist);

    var fromRetriever = retriever.GetWishlistBooks();

    Assert.AreEqual(fromSession, fromRetriever);

Here is how the session is setup for testing….

public abstract class RavenTestsBase

    protected IDocumentSession Session;

    private EmbeddableDocumentStore store;

    [SetUp]

    public void SetUp()

        store = new EmbeddableDocumentStore

                      Configuration = {RunInMemory = true,}

};

         store.Initialize();

         Session = store.OpenSession();

    [TearDown]

    public void TearDown()

        Session.Dispose();

…..I agree - someone is taking the piss. This is so simple I’m worried the cleaner will take my job.

So You Run This With Your Main Test Suite?

They’re fast, but they’re no Ussain Bolt on happy pills….. I run these when any data access code changes and before important commits.

Conclusion

I hope you enjoyed reading about my testing preferences and conventions. Whether you agree with them or not, it’s important to tell yourself how you think the best way to do something is. This gives you a point of reference to take on and incorporate new information – it helps you to improve… and socialise with other developers in the pub.

The most important part is having conventions about how you test. This lets you create consistent tests, that require less cognitive resource to create, maintain and read. You can then put more focus on delivering software and understanding the problem domain.

In part 3 I’ll show you some of my other preferences for web frameworks. Most of them have been learned by playing with FubuMVC.

DDD - Notes from the big blue book. Part 8

2012-01-01T10:14:00.000-08:00

Chapter 15 - Distillation

Identify the core domain and make it small

Identity of the core domain should evolve through iterations

Create a short domain vision statement and revise it as you gain new insights

A domain vision statement gives the team shared direction

Different forms of highlighted core are useful for easily representing the important parts of the core domain eg. distillation document, flagged core

Make it effortless for a developer to know what is in or out of the core

Domain vision statements work in synergy e.g. with a segregated core

Chapter 16 - Large Scale Structures

Large systems that have well grouped modules and bounded contexts can still become unintelligible when there are many of them

Be prepared to drop a system metaphor if it gives poor guidance

Combine layered architecture with responsibility-driven design to achieve responsibility layers

Knowledge models may be appropriate when the roles and responsibilities in a domain can change at runtime

Pluggable component frameworks don't easily allow constant refactoring of the core domain

Large scale structures must enter the ubiquitous language

Chapter 17 - Bringing the Strategy Together

The three basic principles of strategic design are complementary

Context
Distillation
Large-scale structure

When tackling strategic design:

Draw a context map
Verify ubiquitous language is correctly in use
Verify there is a core domain and vision statement
Does the technology choice work for model driven design?
Does dev team have the skills?
Does dev team have knowledge and interest in the domain

Design decisions must reach the entire team

2011 Conceptual Web Framework Utopia – Part 1, “Architecture”

2011-12-18T06:22:00.000-08:00

Bad experiences scar us - forcing us to learn for our own survival. This evolutionary theory can also be applied to software. If you don’t learn from your mistakes, you’ll soon be on this guy’s plate:

So when creating web apps, what have my survival instincts really taught me?

They’ve taught me that almost nothing applies universally. Since I generally create larger-scale web apps, this article applies primarily to that context. Even in this context, though, trade-off benefits will vary for specific circumstances.

They’ve also taught me to isolate the domain, keep the web layer thin and listen to the wise words of people of like Uncle Bob, Udi Dahan & Eric Evans. They’ve even taught me (via Udi Dahan) to “justify why the simplest possible thing isn’t enough” – so expect lots of that too.

In this series of blog posts - reflecting my current thinking - I will be showing:

1. The “Architecture” (clarify the quotes the later)

2. My unit testing strategy

3. A few other preferred patterns

What Does it Look Like?

First, when I talk about architecture, I apply it generally and mean any component of the system as a whole – not just the domain. This contradicts Uncle Bob and may be wrong, but I couldn’t think of another phrase that would be understood that encompassed domain and delivery mechanism(s).

One Model In One Model Out & Endpoint-specific Models

A recent addition I picked up is the OMIOMO (one model in one model out) convention from fubumvc – each action receives a request or input model and returns a view model (or some other model).

By making these models specific to each action, they are very simple data structures – keeping cognitive load to a minimum. It also saves you from having shared view models that introduce bugs when they change for one view and cause another to break.

Endpoint-specific models facilitate the Endpoint Testing Pattern – discussed in part 2.

Endpoints Talk to Domain Services in DTO Language

Transfer of information between endpoints/controllers and domain services is through simple DTO data structures.

Here’s an example:

Endpoint using a query service

public CreateBookViewModel Get(CreateBookLinkModel model)

{

IEnumerable<GenreDto> genres = genreRetriever.GetAllOrderedByName();

return new CreateBookViewModel(genres);

}

Implementation of query service

public IEnumerable<GenreDto> GetAllOrderedByName()

    var genres = session

                 .Query<Genre>()

                 .OrderBy(g => g.Name);

    return genres.Select(g => new GenreDto {Id = g.Id, Name = g.Name});

public bool CanFindGenreWith(string id)

    return session.Query<Genre>().Count(g => g.Id == id) > 0;

Why Bother with DTOs?

Critically, the use of DTOs protects the domain and your application – the contract between your application and domain is a lightweight data structure. With this loose contract, the domain model is free to evolve – and when you’re applying DDD, with the need to refactor often and sometimes aggressively – your domain model has no outside concerns to worry about.

When you do apply domain refactorings, as long as you still meet the contract – the DTO – your application remains unaffected.

I won’t explain the business value of DDD.

Why Separate Services to Query and Command?

A philosophy in CQRS is to separate reads and writes for architectural flexibility. At the heart it is a simple pattern. Generally it appears to be used when reads and writes have a separate data model – but in my case, the domain data model is hidden – so it could be the same or different – we have the flexibility. But what about the cost……

Isn’t Hiding Your Data Access Bad?

In some cases – yes. But for my example, I’d argue – no….domain isolation is worth it. It is a very thin layer, two mouse clicks away and one interface agreement. Data access needs to know domain entities and the underlying data model – to gain the benefits of DDD we don’t want to expose that to the application layers.

I think a thin layer of domain service implementations (not interfaces) that take a dependency on the data access is ok. Some people put them in a separate project, some people chuck it all in the controller – I like this middle ground.

Data access is a tricky, context-specific beast that this is probably the least prescriptive of my ideals.

Using this pattern and RavenDb also gives rise to a good strategy for comprehensive testing of data access – you’ll see that in part 2 as well.

An Example From the Wild

You start out with a synchronous N-Tier application, but your domain model rapidly evolves – with the DTOs being passed between boundaries this is no more difficult than necessary because the domain is isolated.

Suddenly you have multiple bounded contexts, sharing aspects of what once was a single domain entity - so you want to switch to an asynchronous messaging based architecture. As long as you have a separate service for queries and commands, with your data model hidden, you can focus totally on the domain and its contract to the outside world – DTOs.

For those thinking this doesn’t happen – it is the exact situation I am in with the contract I am working on, and appears not uncommon from what I hear elsewhere. If the application followed these principles, changes would be isolated to the domain and we’d only have to worry about meeting service interface criteria – unfortunately there are swathes of inter-twined spaghetti code all through the application and domain that are affected – there’s your business value, son.

So…..

Cowboys have their opinion, those in ivory towers voice quite another. But experience and practice are crucial in finding out what really works and the contexts in which the arguments put forward by each are favourable.

Reflecting on experiences, using personal projects to test assumptions and try new ideas is a great way to get closer to that firm-footing of reality. If you keep doing the same – you’ll keep getting the same. I was pretty bored of those domain entity model binding issues and domain refactorings causing crippling breakages in my web layer - so here’s a small conceptual step, less destined for failure.

Also when you write posts like these, you force yourself to double-check blog posts and podcasts – just to make sure you correctly understood the topic. This reinforces what you’ve learnt, also saving you from any false assumptions you may be carrying on your sleeve.

Tune in for part 2.

Related Shizz

Martin Fowler, CQRS - http://martinfowler.com/bliki/CQRS.html

Uncle Bob, Web Architecture - http://www.cleancoders.com/codecast/clean-code-episode-7/show AND http://skillsmatter.com/podcast/design-architecture/uncle-bob-web-architecture

Udi Dahan talk on SOA - http://skillsmatter.com/podcast/open-source-dot-net/qa-with-udi-dahan

DDD - Notes from the big blue book. Part 7

2011-12-14T14:33:00.000-08:00

Chapter 13 - Refactoring Toward Deeper Insight

Refactoring toward deeper insight may be a response to a problem or awkwardness in the design, where the root of the problem is sensed to be the domain model

May come even when the code looks tidy - but the language just doesn't fit the model

Domain refactorings involve multiple people and are extensively designed and deliberated over

Could be a refinement of ubiquitious language which is then expressed in the code

"If you wait until you can make a complete justification for a change - you've waited too long. Your project is already incurring heavy costs"

Refactor when:

Design does not express current understanding
Implicit concepts can be made explicit
Opportunity to make important parts of the domain more supple

Chapter 14 - Maintaining Model Integrity

Total unification of the domain model will not be feasible or cost-effective

When inside a context, ignore terminology from outside - focus on keeping that context pure

Important to understand the bounds of a context

Duplicate concepts = 2 implementations of the same concept

False cognates = 2 concepts under the same name

Create a visual diagram of all the bounded contexts and translations on a project

Names of bounded contexts should enter the ubiquitous language

Shared kernel, conformist, open host service, published language

Anticorruption layers can be used with external systems or legacy code

Hard for multiple teams to work on one bounded context

For an existing project, draw up the bounded contexts AS THEY ARE

DDD - Notes from the big blue book. Part 6

2011-12-04T06:28:00.000-08:00

Chapter 11 - Applying Analysis Patterns

Have to make calculated compromises to the design to allow for good implementation
Parts of the program we don't suspect can benefit from a domain model - they can be uncovered with analysis patters

Example in this chapter was the nightly script that was run

Analysis patterns are more guiding than prescriptive

Chapter 12 - Relating Design Patterns to the Model

Design patterns can be applied to domain models by thinking about them in a different way - from a domain logic perspective
When applying a design pattern in the domain, first check whether it is a good fit for the domain concept
Example used in this chapter was the composite pattern with nodes representing shipment routes

DDD - Notes from the big blue book. Part 5

2011-12-04T06:19:00.000-08:00

Chapter 9

To find implicit concepts

be aware of hints in the design
search them out
listen to language used and learn
Scrutinise awkwardness of design

Scrutinise code that does awkward things and is hard to explain
Domain experts may be inconsistent - this may indicate an implicit concept
Make constraints explicit
Look at analysis models/patterns
Ideally do not want to make procedures a part of the domain model - unless they are spoken about

Chapter 10

State post conditions of operations and invariants of classes and aggregates - ** maybe as unit test? **
Models are awkward because they are missing pieces - successive refactorings lead to conceptual contours which clarify the model
Decompose design elements consistently with the domain
A requirement that forces extensive change is a sign that the model does not fit
** Closure of operations **
Carve off sub-domains

Fun with Fubu's Html Conventions

2011-11-19T08:39:00.000-08:00

I recently blogged about being impressed with conventions in Fubu MVC that let you decide the rules that govern how actions are discovered, how routes are constructed and displayed, and how output/view selection occurs.

Whilst on my travels in fubu land, the next feature that left me in awe (of the fanboy variety [of awe]) were the html conventions. Read on to learn how they out-muscle and bully ASP.NET MVC ’s display/editor templates for all their dinner money.

As a quick caveat: I am not an expert – these are just my initial findings.

The following example comes from one of my current personal projects.

Establish Context () =>

My first opportunity to apply html conventions came on the create book page hidden in site administration. Take a look at the CreateBookInputModel’s public properties:

public class CreateBookInputModel

{

public String Title { get; set; }

public String Genre { get; set; }

public String Description_BigText { get; set; }

public BookStatus BookStatus { get; set; }

public IList<StringWrapper> Authors { get; set; }

public HttpPostedFileBase Image { get; set; }

}

This public interface would make an excellent contrived example, as it demonstrates a number of different opportunities which get progressively more interesting. But this is a naturally-occurring story.

My goal is to keep the corresponding Spark view very simple – here’s an idyllic vision minus the fluff:

<p>

    ${this.LabelFor(m => m.Title)}

    ${this.InputFor(m => m.Title)}

</p>

<p>

    ${this.LabelFor(m => m.Description_BigText)}

    ${this.InputFor(m => m.Description_BigText).Attr("rows", "5")}

</p>

<p>

    ${this.LabelFor(m => m.BookStatus)}

    ${this.InputFor(m => m.BookStatus)}

</p>

<p>

    ${this.LabelFor(m => m.Genre)}

    ${this.InputFor(m => m.Genres)}

</p>

<p>

    ${this.LabelFor(m => m.Authors)}

    ${this.InputFor(m => m.Authors)}

</p>

<p>

     ${this.LabelFor(m => m.Image)}

     ${this.InputFor(m => m.Image)}

</p>

Let’s start at the Top and Work Down

Strings

public String Title { get; set; }

public String Genre { get; set; }

Simple – strings work straight out of the box with a nicely-named html input as you would expect.

Special Strings

public String Description_BigText { get; set; }

Question: When is a string not a string?

Answer: When I suffix the property name with “_BigText”.

So what is it now then? It’s…..a big blob of text that needs to be represented by a text area – not a text box. To make this happen, head over to my FubuRegistry.

First we need a label:

HtmlConvention(x =>

     x.Labels

      .If(e => e.Accessor.Name.EndsWith("_BigText"))

            .BuildBy(er => new HtmlTag("label").Text(er.Accessor.Name.Replace("_BigText", "")        ))

);

Here, the variable x is the registry, which I’m adding a new label convention to. What I’m saying is, if the property name ends with “_BigText”, build the view portion by using a html label whose text will be the property name, minus the “_BigText” marker (e.g. “Description”).

Now we need an editor to go with the label:

HtmlConvention(x =>

    x.Editors

      .If(e => e.Accessor.Name.EndsWith("_BigText"))

                .BuildBy(er => new HtmlTag("textarea"))

Pretty simple, eh? I’ve just told it to return a text area when the property name ends with our special marker – it is smart enough to give the text area the correct name so you can post values.

Enums

Here’s a favourite, and something I dreamt of doing with ASP.NET MVC, but was not possible with editor templates.

public BookStatus BookStatus { get; set; }

Dear gods of web programming, every time you see an enum to be posted back please be so kind and give me a drop down with each enum member.

HtmlConvention(x =>

     x.Editors

      .If(e => e.Accessor.PropertyType.IsEnum)

           .BuildBy(er =>

                      var tag = new HtmlTag("select");

                      var enumValues = Enum.GetValues(er.Accessor.PropertyType);

                      foreach (var enumValue in enumValues)

                         tag.Children.Add(new HtmlTag("option").Text(enumValue.ToString()));

                      return tag;

})

Once you work out which variables correspond to the property type (er.Accessor.PropertyType) it’s pretty simple to get all the values and make a drop down. Again, the tag you return will automatically have the property name applied, so you can bind the selected value to it nicely.

String Collections

Caveat: fubu mvc doesn’t support binding to a collection of strings yet or IEnumerables (you can add your own, but it’s a bit of work). I just use StringWrapper – which has one string property, “Text”; and ILIst<T> which is supported for binding collections to.

public IList<StringWrapper> Authors { get; set; }

Whenever I see a collection of strings I always want a text box and add button, down which lets you type in text items and build up a list to be posted back. By using some class-name conventions, you can write the JQuery once and it works wherever you use the class name.

But by using fubu-mvc conventions – I write the JQuery once and the class once – the rest is taken care of:

HtmlConvention(x =>

    x.Editors

     .If(e => e.Accessor.PropertyType.IsAssignableFrom(typeof (IList<StringWrapper>)))

               .BuildBy(er =>

                          var tag = new HtmlTag("div").AddClass("hasHiddenGroup");

                          tag.Children.Add(

                                       new HtmlTag("input")

                                           .Attr("type", "text")

                                           .Attr("name", er.Accessor.Name)

);

                          tag.Children.Add(

                                       new HtmlTag("a")

                                            .Attr("href", "#")

                                            .Text("add")

                                            .AddClass("addItem")

);

                          tag.Children.Add(new HtmlTag("ul"));

                          return tag;

                        }));

Start with a div – and give it the magic sauce – “hasHiddenGroup” class (don’t know why I called it that – blame the magic sauce) – then add a text box with the property’s name. Next to that text box, add a link called add.

To clarify, the conventions will build this:

<div class="hasHiddenGroup">

    <input type="text" name="Authors">

    <a href="#" class="addItem">add</a>

   <ul></ul>

</div>

..which means that dash of JQuery can be applied site-wide to wire up the add button - allowing that empty to list to be built up. It then renames each item in the list so they are posted back and can be used to model-bind to.

You can see the simple JQuery code here.

File Uploads

Here’s an easy one:

HtmlConvention(x =>

    x.Editors

      .If(e => e.Accessor.PropertyType.IsAssignableFrom(typeof(HttpPostedFileBase)))

                 .BuildBy(er => new HtmlTag("input").Attr("type", "file"))

);

Closing Thoughts

No doubt about it, the Fubu MVC html conventions go a lot deeper, and are less than brittle than ASP.NET MVC’s Display/Editor templates. When applied to a real world project, the time-savings and bug-reduction have massive potential.

But that’s a production app - this example was based on a small toy project. What may happen in the wild is a mystery

· What happens if the markup is complex and is not so easily created in code?

· What happens if need to apply specific classes?

· What about when I want to override conventions – what pitfalls await me?

I look forward to finding out the answer to these questions, and striving to maintain my intellectually-crippled views.

On a final note you can also use fubu mvc’s html conventions in ASP.NET MVC.

DDD - Notes from the big blue book. Part 4

2011-11-13T10:32:00.000-08:00

Notes from chapters 7 & 8

Chapter 7

When implementing the model- first work out the entities

Association traversal direction represents insight into the domain

Transactional boundaries are allowed to influence the domain model a little

Create modules based on domain relevance

Use anti-corruption layer to translate external systems to ubiquitous language

Don't let domain rules creep into the app layer

Chapter 8

Objects in the domain are not immediately obvious e.g. ship and container were implementation details of a more abstract concept

Example explains how an incoherent model was wrestled into a model driven design

Embrace knowledge breakthroughs and radically change the domain model to reflect it

The breakthrough may cause short term delay - but will most likely be massively worthwhile

Breakthroughs may come after many small refactorings toward deeper insight

Breakthroughs can be the most important part of improving the model design

Breakthroughs can lead to other breakthroughs - this causes development speed to pick up where normally it would drop off

DDD - Notes from the big blue book. Part 3

2011-11-13T09:35:00.000-08:00

Here's what I've cherry-picked from chapters 5 & 6

Chatper 5

Implementing associations between entities in the design can be difficult

3 types of object

Entities
Value types
Services

Modules are part of the model and should reflect concepts in the domain

For every traversable association in the model there is a mechanism in the software with the same properties

Constrain relationships

1-to-many is easier than many-to-many
Ultimate simplification is to remove relationship

Strip entities down to the most common characteristics

Gear them up to be totally about identity

Don't give identity to value types

Parameters and results of services should be domain objects - e.g. money not decimal

Don't let services strip behaviour from entities or value types

Careful use of domain services is key to keeping domain logic in the domain

Use well-defined modules to aid comprehension of the logical groupings of the domain

Modules and entities should co-evolve -- ** they are not fixed **

Don't let frameworks constrain how the model is chunked

Chapter 6

Factories and repositories are allowed in the domain

Aggregate root is responsible for checking invariants

Root may pass reference of nested entity, but receiving object may not keep the reference

Delete the root - and the entire aggregate should go at the same time

Use factories to create entire aggregates as a piece

Consider a coding standard for factory failures

A factory can delegate invariant checking to the aggregate - but not always

Database schema should update to reflect changes in the model

DDD - Notes from the big blue book. Part 2

2011-10-30T06:32:00.000-07:00

Today's notes cover chapter 3 and 4.

Chapter 3

Model must work well as analysis and design

based on domain
but is also solid code that plays well with technology choices

If the model doesn't fit the practical implementations - find a new one

Start with the domain - then make the code fit

Simple application features can be exposed as important domain features

Example of the scripts for the net rules

Reveal the "bones" of the software so users can make the most benefit of the technology

So just have one model
Example was IE favourites
*** Discuss this point ***

Domain modellers have to be coders. This is important for quick feedback and keeping the model consistent with the domain. The book talks about it being impossible to work otherwise

Chapter 4

Responsibility driven design is used in the book as part of domain modelling
Use layered architecture to separate concerns

** Important step is to isolate the domain model **

Don't allow other layers, eg ui, to influence the design of the domain

Put logic like email sending in the infrastructure layer and expose interfaces to the other layers

Important to minimise framework dependencies from the domain model

DDD - Notes from the big blue book. Part 1

2011-10-23T12:17:00.000-07:00

At Wiggle we have just begun a new developer initiative to collectively become better domain modellers. It consists of reading two chapters of the DDD book a week and then having a discussion about them on Friday afternoon.

My homework is now complete – I’ve read the first two chapters…. but I’ve also taken some notes about what I think are the key features. This should give me plenty to talk about on Friday.

A secondary benefit to my notes is that instead of reading the whole book again, I can just go over my notes at regular intervals to help commit the knowledge to long term memory (I’m a fan of brain science so I know a few tricks here).

Anyway, here are my notes for up to the end of chapter 2.

Preface

· A domain model’s ultimate benefit is that it allows successive versions of systems to be built on the existing ones. Eric Evans shows an example of teams not getting to release 2 because they weren’t domain driven.

· Domain model is the most complicated aspect of some systems – not database etc

· DDD must be used with an iterative process (eg. a flavour of agile). There must be close communication between developers and business people/domain experts

· DDD is best applied by a whole team collaboratively, using a shared language

· A domain model is NOT about being “as realistic as possible”. It should loosely represent reality to a particular purpose.

Chapter 1

· 3 rules determine the choice of a model:

o Model and heart of the design shape each other

o Model is the backbone of language used by all team members

o Model is distilled knowledge

· The best developers should also model domains – not working on databases or frameworks

· Effective modelling techniques taken from the PCB example:

o Bind model and implementation

o Cultivate language based on the model

o Knowledge rich domain model

o Distilling the model

o Brainstorming and experimenting

· Knowledge crunching – working towards a simple view that makes sense of the mass

o Models are tried and rejected

o Collaboration between devs and domain experts

· Developers should understand the principles behind the software - not just what it should do

· PCB example was eventually dropped – but those early sessions were the start of the knowledge crunching process that facilitated the later improvements the domain model

· Business activities and rules are as important as the entities

· The maximum booking rule was hidden as a guard clause, but later transformed into a policy. Express domain rules clearly

Chapter 2

· Ubiquitous language

o Spoken by all developers and domain experts – AND expressed in code

o Bottlenecks occur if only certain developers are “bilingual”

o All people must use the same terms to describe the same things

o Domain models can provide the ubiquitous language

o Incorrect use of ubiquitous language will cause developers to clarify true meaning of domain terminology

· Crucial to play around when formulating a ubiquitous language – just like sketching drawings

· Reframe requirements in ubiquitous language as it evolves

· Have only minimal documentation that feels sketchy and disposable to complement the domain model

· Explanatory models of alternative views of the domain can be used as education tools – in no way related to code, though

See you next week suckers

Git-Tfs: Step-by-Step

2011-09-24T09:49:00.000-07:00

I’ve recently had the pleasure of setting up git-tfs to minimise my daily contact with Tfs to an absolute minimum. While the process is quite easy, a few minor things tripped me up and took a bit of faffing and “stackoverflowing” to figure out.

I would hate for other people who don’t have as much time to persevere to just accept tfs. So I made this simple step-by-step guide that is foolproof (VB drag and drop experts excluded).

Install Git for Windows

Head over to the download page for msysgit and pick the latest full installer version. When downloaded, install the application.

You will be asked to select components in a dialog almost immediately. At this point, check the boxes next to “Git Bash Here” and “Git GUI Here” underneath Windows Explorer integration.

After that just keep clicking next and accept the defaults.

Download Git-Tfs

Now make your way to the git-tfs github page. Click the “downloads” button and select the latest package (specifically not the full source code download).

Then extract this package to C:\git-tfs. If you don’t like this location just stick with it for now so you can follow the example. You can move it later on and update things accordingly.

Wire-up Git-Tfs

At this point, git-tfs is not integrated with git. To confirm this, right-click a folder in Windows Explorer and choose “Git Bash here”. If you then type “git-tfs” you will see the command is not found.

Fixing this is easy – you just need to append the path to git-tfs to your “path” environment variable:

· Click start/windows icon

· Right-click on “Computer” and select “Properties”

· Select “Advanced System Settings”

· Click the “Environment Variables” button

· Edit the “Path” System variable – append it with “;C:\git-tfs”

You can confirm this worked by opening up the bash again (on any folder) and trying the “git-tfs” command and observing the available options

Cloning a Repository

Here we have to make contact with the Tfs server. But first, we need to find the path to it. The easiest way to do this is to:

1. Open visual studio

2. Click the “Team” drop down menu

3. Select “Connect to team foundation server”

4. Click the “Servers” button

5. Note down the url of the server you want to access

Now you need need to suffix the Tfs path with the name of the collection that contains the repository you want to checkout and work on – quickest way to find this is right at the top of the “Team Explorer” floating menu in Visual studio. You can also see them on the image above (e.g. DefaultCollection).

For example: http://Tfs:1000/DefaultCollection

The last bit of required information is the name of the branch you want to work on (clone). If you select a branch inside Tfs’s “Source Control Explorer” tab, it will give you this, starting with “$” in the “Source Location” text box right at the top. E.g. $/this/is/my/branch

With all the information available, click on a folder in windows explorer where you’d like to check out your branch and create a git repository. Select “Git Bash here”, then the command: git clone <tfsurl /collection name> <name of branch, starting with $>.

Git will now do its magic and you’re ready to go.

Ignoring Files

Setting up a global ignore file is something you’ll want to do to avoid committing all those ReSharper and debug files. This is quite simple to achieve:

· Navigate to your user directory e.g. c:/Users/YourMom

· Create a file called “.gitignore_global.txt”

· Shift+right-click inside the window and “open a command window here”

· Type the command “REN .gitignore_global.txt .gitignore_global”

Now you need to register this file with git: bring up a bash anywhere and type: git config --global core.excludesfile ~/.gitignore_global

To confirm it worked, in the bash type: git config --global core.excludesfile. It should echo back the full path to the ignore file.

To get you started with some exclusion rules, try opening the .gitignore_global file with notepad and add these lines:

*ReSharper*/

*bin*

.gitignore

Google and the phrase “gitignore” will teach you the rest.

FubuMVC - My Starting Conventions

2011-09-11T09:58:00.000-07:00

I finally had to scratch the itch and put my other toy projects on hold to have a play with RavenDB and FubuMVC. Immediately, I found my first point of interest – and one of FubuMVC’s selling points – pluggable conventions.

In a minute I’ll show you the conventions I have chosen as a starting point – I’ve taken inspiration from elsewhere, and myself imagined what works theoretically. These conventions relate to defining actions – which methods in code are accessible to the web; and basic url patterns. Finally I’ll show my starting convention for view-location as well.

Action Per-Controller

It seems as fashionable as coding in Node.js at the moment, but actually, when you’ve worked on an ASP.NET MVC project with bloated controllers – a ridiculous amount of actions, and insane number of injected dependencies – having one action per-controller is rather practical. Because we define our own url policy, we’re not constrained by the framework where code has to live.

My implementation will mean the name of the controller is the name of action, while the name of the method is the http verb it responds to. Here’s an example:

public class PiggyBankEndpoint

         public PiggyBankViewModel Get()

              return new PiggyBankViewModel();

         public String Post(DepositInputModel model)

              // do some stuff with the model

              return "Pennies in the piggy";

Oh, and by the way, I think I’m cool, so I don’t use the word controller – I copy the cool kids and call them endpoints (although WCF isn’t cool).

Here’s where you’ll Find All the Action

Inside the constructor of my Fubu Registry, where I declare my basic conventions for deciding what an action is, I have this little snippet:

Actions

.IncludeTypes(t => t.Namespace.Contains("Web.Endpoints") && t.Name.EndsWith("Endpoint"));

No, I won’t patronise you – I’m not a Microsoft MVP (joke).

I Bet Those Url’s Look Messy

Before I applied my conventions – yes, yes they rather did. After my convention, though, now I’m cool again.

Routes

    .IgnoreNamespaceText("Endpoints")

    .IgnoreClassSuffix("Endpoint")

    .IgnoreMethodsNamed("get")

    .IgnoreMethodsNamed("post")

    .ConstrainToHttpMethod(x => x.Method.Name.Equals("Get"), "Get")

    .ConstrainToHttpMethod(x => x.Method.Name.Equals("Post"), "Post")

    .RootAtAssemblyNamespace();

This time I will patronise you – because I want to be an MVP now.

So FubuMVC is going to use the namespace, the type of the controller and the name of the action. I’ve decided that doesn’t fit with my desired url conventions. So instead, I’m saying:

· Do attempt that Mr FubuMVC

· But strip out the word Endpoints from the url if it appears in a type’s namespace

· Again, if a type’s name ends with Endpoint (which my convention says they all will), then don’t put this in the url either

· If there is a method called get or post – remove the name of the method from the url and only allow access for the http method with the same name

Shut Up and Show Me

Here are my endpoints:

Their type names ends with “Endpoint” and their namespace contains “Web.EndPoints” (oops – I patronised you J), so public methods for these types are my actions.

Using another selling point of Fubu, the basic diagnostics, we can now check what actions are available and the constraints that are applied to them:

Excellent – yes, FubuMVC is using the namespaces and type names to determine url structure. But with a few simple fluent configuration options, I’ve tweaked it to my liking.

Take Me to Your Views

Views

     .TryToAttach(x => x.by_ViewModel());

     this.UseSpark();

Simple again – look for the view whose view model matches the return type of the action – they can live anywhere (for now). Below that I’ve said I’m using the spark view engine – NuGet: Install-Package FubuMVC.Spark.

What Am I Thinking?

I’m thinking it can seem overwhelming to have to define your own conventions…but actually, it’s not. With the diagnostics to fall back on, at this early stage (approx. 30 lines of my own code), everything is definitely under control – jus make one small change at a time and observe how things change in the diagnostics.

Have I seen anything here that gives me confidence FubuMVC is an alternative – maybe even a better one – to ASP.NET MVC? Why yes, yes I have. “FubuMVC – the web framework that get’s out of your way” – it actually does.

It’s very early days, though, and I’m a bit of a fan boy – take me with a pinch of salt.

WPF DataGrid DataDialogs

2011-08-20T03:52:00.000-07:00

Intro

As a WPF flirt I can’t give you best practices or ideals - but I can give you a simple technique for adding buttons to each row in a WPF DataGrid that (in this case) will display contextual information in a dialog box.

It will also provide a good reference to my future self when the gods of HTML reclaim the UI portion of my brain (the part that is pathetic at visual designs).

Data Model

To celebrate BT’s double screw-up at trying to get broadband installed in my new home, this demo will be based on companies that suck. Hence…

public class CompanyThatSucks

{

private readonly String _reason;

public CompanyThatSucks(string name, int suckynessRating, int

howMuchWouldILoveToSeeThemGoBankrupt, string reason)

{

Name = name;

SuckynessRating = suckynessRating;

HowMuchWouldILoveToSeeThemGoBankrupt = howMuchWouldILoveToSeeThemGoBankrupt;

_reason = reason;

}

public String Name { get; private set; }

public Int32 SuckynessRating { get; private set; }

public Int32 HowMuchWouldILoveToSeeThemGoBankrupt { get; private set; }

public String GetReasonForSucking()

{

return _reason;

}

Data on Display

Hooked up via data binding to a view model, here is the live list of companies that suck. Because I share this list with my mom, and she moans by the essay, it would take too much space to show the reason in a cell. So I’ll pop it up in a dialog when a button is pressed.

DataGrid Action Buttons

Here’s what we want, right?:

Here’s how to get it:

public MainWindow()

    InitializeComponent();

    this.DataContext = new ViewModel();

    "Suckers is the DataGrid"

     Suckers.Loaded += (x, y) => AddShowNotesColumnToDataGrid();

private void AddShowNotesColumnToDataGrid()

   var button = new FrameworkElementFactory(typeof (Button));

    button.SetValue(Button.ContentProperty, "Show Notes");

    button.AddHandler(Button.ClickEvent,

    var column = new DataGridTemplateColumn

              CellTemplate = new DataTemplate() { VisualTree = button},

               DisplayIndex = 3,

};

    Suckers.Columns.Add(column);

}

1. Create a button thingy with that factory thingy

2. Set the button’s text

3. Create a new column for the DataGrid and mangle it to contain the button

a. The DisplayIndex affects ordering of the columns – this one is at the end

4. Add the column to the DataGrid

This Relationship is all about the Dialog

In two simple steps we can make that ornamental button come to life quicker than you can cancel your account with BT (I have the stats).

1. Create a Simple Method to Show a Dialog

 private void ShowDialog(string content)

       var w = new Window

                 Height = 400,

                 Width = 400,

};

            w.Content = new TextBox

                  Text = content,

                  Foreground = new SolidColorBrush(Colors.White),

              Background = new SolidColorBrush(Colors.Black)

};

          w.ShowDialog();

}

2. Bind to the Button’s Event Handler

This step of my trick is where the buttons actually do something that relates to the row of data they represent. There are two sub-steps.

1. Get the “Reason for sucking” from a button

private string GetReasonForSucking(Button sender)

    var companyThatSucks = (CompanyThatSucks)sender.DataContext;

    return companyThatSucks.GetReasonForSucking();

}

2. Actually bind to the button’s handler

button.AddHandler(Button.ClickEvent,

                                   new RoutedEventHandler((sender, args) => ShowDialog(GetReasonForSucking((Button)sender))));

Here I’m binding to the button’s click event. I’m using the method in sub-step 1 above to get information from the button’s data context and present it to the user in a dialog using the other little method I created above. This code goes below the line that sets the buttons text.

Result

Conclusion

Today’s moral of the story is to not get angry with certain organisations because they repeatedly inconvenience you after you trip over yourself triple-confirming things will happen on certain days.

The sub-plot was a little less abstract - an education in one technique for augmenting the functionality of a WPF DataGrid by adding custom buttons that can perform actions specific to the row of data they belong to.

UK Date Validation For JQuery Validate

2011-06-29T12:06:00.000-07:00

Recently I was making tweaks to a Monorail project and was required to add date validation. The default configuration using active record correctly applied the class “date” to the fields, which is a flag for JQuery validate.

Unfortunately, JQuery validate uses the American date format (mm/dd/yyyy). I had a play with the settings but could not find a hook to specify a UK date format. So I had to try something a bit different – I created a custom JQuery validate method.

You might also find this link useful: http://geekswithblogs.net/EltonStoneman/archive/2009/10/29/jquery-date-validation-in-chrome.aspx

Preparation

To replicate my solution you’ll need a reference to three files:

· JQuery

· JQuery validate

· Date.js (Date.js.com)

Laying down the rule

Using the validator I plugged in a new rule that parses the value using a date format. If the parse fails, then validation fails. This is where Date.js comes in – the Date.parseExact method. Notice the single characters for day and moth – this allows one or two digits.

$.validator.addMethod(

"validateDate",

function (value, element) {

try {

if (!value) {

return true;

}

var d = Date.parseExact(value, "d/M/yyyy");

if (d == null) {

return false;

} else {

return true;

}

catch (e) {

return false;

}

"Please enter a valid UK date dd/mm/yyyy"

);

Apply the rule

The final step is to apply the validation to elements using a css selector. In this case I chose all items with a class called “validateDate”:

$('.validateDate').validate({

name: "validateDate"

});

Give it a whirl

Here is the result of using a weird American date format:

And here’s the result of being normal (not that I recommend it):

A full example

Here’s the sample html page I used to test it out. Don’t forget to download Date.js if you try it out.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

<title>Uk Date Validation</title>

$(document).ready(function () {

$('form').validate();

wireUpDateValidation();

});

function wireUpDateValidation() {

$.validator.addMethod(

"validateDate",

function (value, element) {

try {

if (!value) {

return true;

}

var d = Date.parseExact(value, "d/M/yyyy");

if (d == null) {

return false;

} else {

return true;

}

catch (e) {

return false;

}

"Please enter a valid UK date dd/mm/yyyy"

);

$('.validateDate').validate({

name: "validateDate"

});

}

</script>

</head>

<body>

<label>

Uk date:

</label>

</form>

</body>

</html>

Clean Code Tricks – Intention Revealing Messages

2011-05-15T11:20:00.000-07:00

Intro

It’s easy to dismiss “clean code” as a myth or “only for the perfectionist”, and who am I to say that is wrong? Well, I can’t say it, what I will say is that I have found clean code to be real, to be immediately valuable and to be an easy habit to get into. I have found clean code reduces the cognitive load when you are trying to unravel the mysteries in code.

I’ve picked up some clean code techniques from www.cleancoders.com (Uncle Bob), Code Complete 2 (Steve McConnell), and Smalltalk Best Practice Patterns (Kent Beck). I’m also always on the lookout for more.

In this indefinite series of posts, I’ll share my favourite techniques and the reasons why I love them.

As always, I continue to learn and respect other people’s opinions. Nothing is part of my religion – just the way I currently perceive as the best approach to writing code. If I gain new insights from others or from my own adventures, I’ll be sure to present them.

Intention Revealing Messages

Intention revealing messages are at the heart of clean code - they are methods which contain only small pieces of code. Their goal - to explain what the small piece of code, sometimes just a single line, means.

My favourite place for intention revealing messages is the conditional in an “if statement”.

Benefit

If a method name tells me what the condition means:

· I don’t have to work it out myself

o Saves me time

o saves me hassle

o saves my company money

o reduces potential for misinterpretation

o highlights a bug (where the name doesn’t match the implementation)

Cost

A method signature and a pair of curly braces - sounds like a deal.

An Example

if (row > 0)

Rows[row][column].Above = Rows[row - 1][column];

This is one if block in a block of 5 and I’m trying to find a bug which could live in any of them.

First of all, I have to work out what the author intended. What does row > 0 mean? After reading associated code for a few minutes, it means “not the top row”.

I then have to work out what the code block means – “set the cell above reference on this cell, using the cell above this one in the row above” – which takes more time.

Now imagine that this block of code is only a smart part of a larger area of code which might have the bug – I’ve got to decode lots of implementations to work out the high-level algorithm – and then check the implementations match what I “think” the author intended.

A solution

If I refactor small implementations into methods (intention revealing messages), for each block, no-one has to work out the intentions – only that the implementations match the intentions, or the intentions are wrong:

if (!IsTopRow(row))

SetCellAbove(row, column);

Now I can walk through the code and read the algorithm in English language. If the algorithm should work theoretically, then I can check intentions (method names) against implementations (method bodies) - the bugs will jump out at me. If the algorithm is flawed, then I don’t need to need to dip into any implementation.

Note: I've inverted the expression to keep the query positive (a common standard)

Source

Intention revealing methods are presented in Smalltalk Best Practice Patterns Using them in this way is recommended by Rob Martin (Uncle Bob) on www.cleancoders.com (episode 3).

From MVC to MVVM in WPF - My Findings

2011-04-09T13:46:00.000-07:00

The design for my exciting Multi-touch Music Catalogue is a typical MVC architecture. Or at least it was. Once I’d got to the end of the first iteration’s coding, I suddenly remembered reading in CODE magazine about the MVVM pattern. A bit of googling later and this is the de-facto architecture in WPF, Silverlight and WP7 – no question.

An opportunity had now presented itself for me to understand why it is the de-facto standard – and why it is better than MVC / MVP with which I am more familiar. Below are my findings specific to this project.

Current Setup

Using MVC / MVP, the controller/view setup looks like this – with the view having to implement the IMusicView interface– in the process agreeing to provide behaviour to maintain state and control the UI – specific methods for transitioning between display modes.

Controller Interface

public interface IMusicController

{

IMusicView View { get; set; }

IEnumerable<Tag> GetTags();

void SetSongMode();

void SongSearch(string tag, int limit = 10, int page = 1);

void SetSongDetailsMode(int songId);

Stream GetImage(string url);

}

View Interface

public interface IMusicView

{

ViewMode Mode { get; set; }

IMusicController Controller { get; set; }

IEnumerable<Tag> Tags { get; set; }

IEnumerable<Song> Songs { get; set; }

Song Song { get; set; }

string StatusMessage { get; set; }

void SetSongMode();

void SetSongDetailsMode();

Stream GetImage(Release release);

}

Combining View/Controller logic into a ViewModel

If I was working top-down (my usual preference) the view would tell me what properties my model needs. But this view is quite simple, so I can work from controller and view interfaces to create the view model and I won’t be too far away from where I need to be.

Step 1 – Straight-copy of data from view interface

Properties on the current view interface are the data items the view needs. So they are a straight swap to the view model (excluding the controller). The mode property is an interesting one because the view doesn’t need it. But I’ll take it anyway (and reconsider later).

View model created with presentation data

public class MusicCatalogueViewModel

{

public ViewMode Mode { get; set; }

public IEnumerable<Tag> Tags { get; set; }

public IEnumerable<Song> Songs { get; set; }

public Song Song { get; set; }

public string StatusMessage { get; set; }

}

Step 2 – Translating view methods

Methods of the view interface correspond to commands in WPF. So at this point, I’ll create the commands and add them to the VM. Notice here that logic previously needed to be implemented by every view, is now relocated to the view model, as commands, and implemented for any view that uses the model.

I’ve had to remove the GetImage method because it doesn’t fit with MVVM. So I’ve relocated it to the song class. At this stage the un-implemented commands are also not a concern.

View model updated with presentation behaviour

public class MusicCatalogueViewModel

{

public ViewMode Mode { get; set; }

public IEnumerable<Tag> Tags { get; set; }

public IEnumerable<Song> Songs { get; set; }

public Song Song { get; set; }

public string StatusMessage { get; set; }

public ICommand SetSongMode

{

get { return new SetSongModeCommand(this); }

}

public ICommand SetSongDetailsMode

{

get { return new SetSongDetailsModelCommand(this); }

}

Step 3 – Translating controller methods

Behaviour currently on the controller (arguably presenter) now also belongs in the VM too

View model updated with controller behaviour

public class MusicCatalogueViewModel

{

public ViewMode Mode { get; set; }

public IEnumerable<Tag> Tags { get; set; }

public IEnumerable<Song> Songs { get; set; }

public Song Song { get; set; }

public string StatusMessage { get; set; }

public ICommand SetSongMode

{

get { return new SetSongModeCommand(this); }

}

public ICommand SetSongDetailsMode

{

get { return new SetSongDetailsModelCommand(this); }

}

public ICommand SongSearch

{

get { return new SongSearchCommand(this); }

}

One new addition, SongSearch, is the only code needed from the controller; mainly because the methods on the view delegated responsibility to a similar method on the controller. Logic previously in the controller will now be relocated to the appropriated commands (ICommand).

Implementing INotifyPropertyChanged

In a nutshell, to keep view elements and the data they bind to synchronised, a VM must announce when one of its properties has changed. It does this by implementing INotifyPropertyChanged and specifying when an update occurs.

View model after implementing INotifyPropertyChanged

public class MusicCatalogueViewModel : INotifyPropertyChanged

{

private Song _song;

private IEnumerable<Tag> _tags;

private IEnumerable<Song> _songs;

private string _statusMessage;

public ViewMode Mode { get; set; }

public IEnumerable<Tag> Tags

{

get { return _tags; }

set

{

_tags = value;

NotifyPropertyChanged("Tags");

}

public IEnumerable<Song> Songs

{

get { return _songs; }

set

{

_songs = value;

NotifyPropertyChanged("Songs");

}

public Song Song

{

get { return _song; }

set

{

_song = value;

NotifyPropertyChanged("Song");

}

public string StatusMessage

{

get { return _statusMessage; }

set

{

_statusMessage = value;

NotifyPropertyChanged("StatusMessage");

}

public ICommand SetSongMode

{

get { return new SetSongModeCommand(this); }

}

public ICommand SetSongDetailsMode

{

get { return new SetSongDetailsModelCommand(this); }

}

public ICommand SongSearch

{

get { return new SongSearchCommand(this); }

}

public event PropertyChangedEventHandler PropertyChanged;

public void NotifyPropertyChanged(string propertyName)

{

if (PropertyChanged != null)

{

PropertyChanged(this,

new PropertyChangedEventArgs(propertyName));

}

Advantages of MVVM in this Example

Having made the switch from MVC to MVVM the first obvious benefit is lack of logic in the view – zilch to be precise. The further away from SmartUI the better.

In my tests and executable specifications, I can now do away with test doubles for the view. I black-box text my VM – as long as it works, all the view has to do is bind to the properties and commands (from a functional perspective).

Because the previously view and controller logic now sit in the VM, there is less overall code – no more view event handlers delegating calls to the controller. Less code is generally better, I think most would agree.

MVVM works in in WPF, Silverlight and WP7 in the same way. So if I make my application work on any of those platforms, I’ve got excellent reuse potential. Or If I create other applications – the foundational knowledge for developing them in an effective way.

Drawbacks

Whereas MVC / MVP requires an interface and thus compile-time checking – MVVM has none of that – and for the same reason – view binds to properties via “magic strings” - there is no refactoring support.

Announcing a property has changed generally involves calling NotifyPropertyChanged in the setter – yes the setter – we now have backing fields for all view-bound properties. Small potatoes, though really.

What if I wanted to use this view model with another UI technology that doesn’t support data binding via INotifyPropertyChanged – well, you’d probably see something different – whereas MVC your new view just implements the interface and provides its own presentational behaviours. Off the top of my head, I can only imagine that’s WinForms – and not a concern for me.

Conclusion

Switching from MVC to MVVM has been a relatively trivial task once I’d read a few blogs and watched a screencast or two. For my efforts I have an application that now works a way more suited to WPF. I also have a good understanding of how to design applications for not just WPF, but Silverlight and WP7 as well.

Now all my tests and executable specifications have broken. Better go and fix them so I can push my changes and allow you all to play with my code and tell me how there are millions of ways to do it better.

Multi-Touch Music Catalogue – Part 1: Getting Started

2011-03-27T13:22:00.000-07:00

Intro

Towards the end of 2011 I went to a talk on multi-touch in .NET at NxtGenUG Birmingham, by Guy Smith Ferrier. This was my first experience of multi-touch and I was amazed at how ready the technology was for developers. Basically, it’s here – go use it, get stuck in, have some fun.

As a treat I bought myself a multi-touch capable monitor, the Dell SX2210T for Christmas. Early this year I was then looking for a multi-touch book. Guy Smith Ferrier kindly pointed me towards Josh Blake’s Natural User Interfaces in .NET early access edition –which I’ve made good progress with and highly recommend.

So now I’m at a stage where I want to develop an application and see what damage I can do with the multi-touch API’s available to me. As it happens, I also want to learn Git and play with a new agile ‘project management’ toy SpecLog. So I had an idea – I’ll create a multi-touch music catalogue using all of these tools – sweet!

To get data into my application I’ll be using the 7Digital API. In a simple spike project I found it really easy to work with; the documentation is great; and I got a riposte to a query on the mailing list. Also, if it’s good enough for Spotify and the BlackBerry Music App, it should (just about) meet my exquisite demands. As a side-benefit, I’ll have a nice .NET API that wraps their API which may be of use to others.

While creating the application I’ll be blogging about what I’ve learnt from the tools I’m using and decisions I’ve made with my application. I’ll also be welcoming of any comments, criticisms and suggestions about absolutely anything – usability (especially NUI), coding style, architecture, testing, specs, go crazy folks.

Creating my GitHub Repository

My first task was to create an empty solution and get it hosted on GitHub. This actually took me about an hour or two. But that was because I did plenty of research, and I’m glad I did – everything has run smoothly since then.

Initially I followed the getting started advice on GitHub and read the first two chapters of the recommended reading. I followed that up by downloading two tools: one that makes working with git on Windows easy; and one for Visual Studio integration. I have to thank Krzystof Kozmic for making me aware of these tools in this blog post.

Now my application has a permanent home on GitHub. Here is the repository if you want to check out current progress.

Capturing my Requirements with SpecLog

For almost a year now I’ve been using SpecFlow to create executable specifications on some of my projects. Check out my “BDD” blog posts if you’d like to see how I have used (and abused) SpecFlow.

The guys at TechTalk who created SpecFlow have now created SpecLog which they say is ‘designed for managing requirements in agile projects’. On their website you can see some clips that show you how to use it – personally I think they are very impressive – but I haven’t used many tools of this nature – so take my opinions for what they are worth.

For my Multi-Touch Music Catalogue, I used SpecLog to plan 7 iterations (which will probably change). Doing this I was able to relate user stories to business goals – and then link user stories to the feature files I had created in my Visual Studio solution. With this done I can associate information with user stories like comments and images – obviously more useful in a multi-developer production environment.

I have found SpecLog to be very friendly. Some of the windows are a little small, but apart from that it has good usability and is notably easy on the eye.

Above is a screenshot of my requirements for iteration 1 – totally related to the business goal of allowing users to search for songs. The graphical relationship between business goals and user stories is a nice touch – and psychologically this kind of diagram is almost proven to help you understand the information it represents.

I have only written the user stories for the first few iterations, the rest are just business goals that I will flesh out later or change as my ideas for the application do. In an ‘enterprise’ environment, you would probably lay out all the stories on your main work space and then devise your exact iterations at the start of the project (I would guess).

In the above screenshot, you can see the details for a particular user story – note how I’ve linked it to a feature file in the solution and it has imported that feature file. I can see the obvious benefit here of non-developers, clients maybe, using SpecLog to keep tabs on what the developers are working on and the project’s progress.

The “Add criterion” button allows comments and images to be associated with this file, which again seems to be a nice touch (but I haven’t trialled in a production environment).

If you want to have a look at my SpecLog repository and see exactly what I’ve been upto, you can get it from my GitHub page and open with SpecLog which you can download here.

Plan

My plan for the application is quite simple, and fits with my reasons for creating the application. Iteration 1 is all about getting some basic functionality. Iteration 2 is then going crazy with multi-touch features (such as multiple layout options) which is the main reason I am creating the application. Although every iteration may include multi-touch improvements, iteration 2 is a pure multi-touch R & D experience.

Following iterations then add more functionality up to the point where you can purchase songs – although making profit it not the goal. But if I’m in a position where people want to use this application to purchase songs, then I’ll be happy to let them – the 7Digital API is fully supportive of this. Personally, I’d be content knowing that people just want to use the application (it’s not a load of pants basically).

Conclusion

Exciting times are ahead due to this project which epitomises why I love software development – there are always new tools and technologies, and so many options that let you be creative and imaginative. At the same time you get some nice object-oriented challenges to sink your teeth into (in this case creating the service that will communicate with the 7Digital API).

It would be great if you could contribute and share your opinions.

Gembox Excel Downloads in ASP.NET MVC

2011-03-03T10:02:00.000-08:00

Excel – the number-crunching tool of choice for business-bods the world over. If you’re developing complex, bespoke web-apps for these folk then Excel downloads are invaluable…inevitable…inexorable. They want their data in .csv, .xls, .xlsx and even .iWantThisTodayButIllWantThatTomorrowAndSomethingElseNextWeek.

My tool of choice for catering to Excel needs in .NET is Gembox. “Word” has it the Office Interop libraries lack the full capabilities you’ll need and most importantly are a drain on critical performance in a web environment.

Gembox, however great, likes to work with streams – output streams in particular. Give it a memory stream, and it will give you hassle. So this makes life impossible when working with the FileResult in an MVC controller.

The examples available on the official site show Gembox files being written directly to the response’s output stream. But no – not in an MVC controller????

Don’t be silly – unless you’re a cow boy. In which case, switch off now and lasso that tightly-coupled spaghetti code into all sorts of future-pain shaped pieces.

For those of use sitting on the scale between conscientious and perfectionist - and for the record, I only just make the grade – then for us people, we create a custom action result, and do all our interaction with the response in that little haven. We also do it in a flexible way which encapsulates the logic bound to ASP.NET MVC interfaces.

Alas, you’re probably gagging for code, so feast on this:

public abstract class ExcelResult : ActionResult

{

private readonly ExcelFile _file;

private readonly string _fileName;

protected ExcelResult(ExcelFile file, string fileName)

{

_file = file;

_fileName = fileName;

}

protected abstract string ContentType { get; }

protected abstract string Extension { get; }

protected abstract Action<ExcelFile, Stream> SaveAction { get; }

public override void ExecuteResult(ControllerContext context)

{

context.HttpContext.Response.Clear();

context.HttpContext.Response.ContentType = ContentType;

context.HttpContext.Response.AddHeader("Content-disposition", "filename=" + _fileName + Extension);

SaveAction(_file, context.HttpContext.Response.OutputStream);

}

Essentially, this abstract class contains the logic that sets up the response, but parameterises the actual data and the file name. It also defines an interface that types of Excel file (csv, xls, xlsx, blah-bluh-bleh) must provide implementations for –content type and the file extension.

SaveAction is the “parameter” which provides the data - it takes a method with two parameters – the Gembox ExcelFile you supply in the constructor and a Stream – which you can see is the Reponse.OutputStream. All the base class wants you to do is put the data in the stream and think happy thoughts.

If the interface for ExecuteMethod on ActionResult changes in a future version of MVC, we only have to tweak the method in this base class. If we also wanted to use different Excel providers, we could use an IExcelFile interface. Yagni, Yagni, Yagni. Ok, you get the get message. I’ve just done what’s needed here, but made life easy in the future without any cost now and been bone-DRY in the process.

An example of a concrete class, in this case for Csv files produced by Gembox, would look remarkably similar to this:

public class CsvResult : ExcelResult

{

public CsvResult(ExcelFile file, string fileName)

: base(file, fileName)

{

}

protected override string ContentType

{

get { return "application/csv"; }

}

protected override string Extension

{

get { return ".csv"; }

}

protected override Action<ExcelFile, Stream> SaveAction

{

get { return (f, s) => f.SaveCsv(s, CsvType.CommaDelimited); }

}

I’m lost for words. There’s absolutely nothing to talk about – so simple it explains itself. If you now need to create one for .xls, .xlsx or some of the other open formats supported by Gembox, then all the hard work has been done.

To use these custom results, return a new instance of the desired sub-class, passing the Gembox ExcelFile along with a filename. Your users get an Excel document and your colleagues will think you're cool.

Augmenting the [AutoLoad] - Logical Parameter Names

2011-01-24T13:19:00.000-08:00

Introduction

A few days ago I blogged about my custom model binder attribute for model binding to entities managed by a persistence framework. I also mentioned, there were a number of ways it could be improved. And since then, I’ve had even more ideas.

The most fundamental issue was the parameter names – I can’t bind to a parameter called “id” just because that is the key of a key-value pair supplied by the request. This coupling has to be destroyed.

Separating Model Names and Request Names

At the moment, when model binding, the key for a value sent in the request, must match the name of the parameter that the model binder works on. But this isn’t good. Can you see why?

public ViewResult Details([AutoLoad]HealthFood id)

{

return View(id);

}

Yes, I know you can – the name id doesn’t make sense and it makes me feel insecure about my employment status. Fortunately, we can keep the attribute concise, and have flexibility with parameter names. It’s a two-step process:

1. Tell the model binder what key to look for and ignore the name of the parameter

2. Add an option to manually specify the key

So the current key is the ModelName – the name of the parameter:

var valueKey = bindingContext.ModelName;

What I’m going to do is step in here and say, the default is now “id” unless I tell you otherwise. The updated code looks like so:

private const string DefaultValueKey = "id";

private string ValueKey { get; set; }

public AutoLoadModelBinder(string valueKey = DefaultValueKey)

{

ValueKey = valueKey;

}

public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)

{

var typeBeingBoundTo = bindingContext.ModelType;

var rawValue = bindingContext.ValueProvider.GetValue(ValueKey);

Have a quick glance at the constant “DefaultValueKey” with the value id. If no value is specified as the constructor’s optional parameter, then this is the key that the value provider will be queried for. And obviously, to override, you just pass your desired key into the constructor.

Keeping the AutoLoad Attrbute in Sync

We’ve allowed the binder to specify a key, but the key will need to be propagated down from the attribute. Again, that’s really trivial and it looks like so:

public class AutoLoadAttribute : CustomModelBinderAttribute

{

private readonly string _valueKey;

public AutoLoadAttribute(string valueKey)

{

_valueKey = valueKey;

}

public AutoLoadAttribute()

{

}

public override IModelBinder GetBinder()

{

return !string.IsNullOrEmpty(_valueKey)

? new AutoLoadModelBinder(_valueKey)

: new AutoLoadModelBinder();

}

Attributes and default parameters don’t like to play nicely, so we have to have an overload for the constructor. But the rest is pretty self explanatory.

If I now go back to my details action, and just change the name of the parameter:

public ViewResult Details([AutoLoad]HealthFood healthFood)

{

return View(healthFood);

}

Not only does the code make sense, but it actually still works. Fantastico.

The assumption here is that the form posts the id for this HealthFood using the name “id” – the default value in the model binder. But if it wasn’t and it was “healthFoodId”, well I could just do this:

public ViewResult Details([AutoLoad("healthFoodId")]HealthFood healthFood)

Why is This Useful?

Good question. Let’s say you are creating an object, like HealthFood, that has a many-to-many association with “HealthBenefit”. You might want to create a new instance of HealthFood, and model bind to a HealthBenefit, using the name “healthBenefitId”, which you can then associate in the controller directly, rather than via a repository query – bleugh!.

Conclusion

After a successful proof-of-concept in the last post for elegant, opt-int model-binding to persistent entities, work needs to be done to tidy up and add significant value to the [AutoLoad] custom model binder attribute. In this blog post I removed the coupling between the parameter name and the key of the value in the request being bound to.

I've still managed to dodge the bullet of making this tool ORM-agnostic and I am to still to make it work on Http Post requests. Let's not forget, we'd like to model bind to collections - on their own, or as child entities of other domain entities.

Plenty more to come then.

public class AutoLoadModelBinder : DefaultModelBinder

{

private const string DefaultValueKey = "id";

private string ValueKey { get; set; }

public AutoLoadModelBinder(string valueKey = DefaultValueKey)

{

ValueKey = valueKey;

}

public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)

{

var typeBeingBoundTo = bindingContext.ModelType;

var rawValue = bindingContext.ValueProvider.GetValue(ValueKey);

var entityId = Convert.ToInt32(rawValue.RawValue);

//TODO - tied to implementation details - I know

var dataContext = new AutoLoadModelBinderExampleContext();

var allItemsOfType = dataContext.Set(typeBeingBoundTo);

var entityBeingBoundTo = allItemsOfType.Find(new object[] {entityId});

return entityBeingBoundTo;

}

public class AutoLoadAttribute : CustomModelBinderAttribute

{

private readonly string _valueKey;

public AutoLoadAttribute(string valueKey)

{

_valueKey = valueKey;

}

public AutoLoadAttribute()

{

}

public override IModelBinder GetBinder()

{

return !string.IsNullOrEmpty(_valueKey)

? new AutoLoadModelBinder(_valueKey)

: new AutoLoadModelBinder();

}

Elegant, Opt-in Model Binding to Persistence Entities in ASP.NET MVC

2011-01-22T06:50:00.000-08:00

Introduction

ASP.NET MVC is awesome. I really enjoy programming with it. Two features that make it great are its “plugability” and extensibility; which is good – because I feel the default model binder can be improved in certain scenarios. One such scenario is when you want to get persistent entities from a repository via your ORM tool. Rather than taking an ID and doing a query – just model bind straight to it.

Negatives to this approach are that it could cause security concerns if you have nested persistent entities automatically loaded based on form values. So ideally, you want to opt-in to this model binder – but you don’t want the opt-in to be a verbose attribute declaration (more on this later).

For me, the ideal is an elegant, but obvious declaration. And for me, I have this ideal. Read on and it can be yours too.

Shut Up and Code

Rather than just showing the implementation, I’m going to show you a working example. To do this I’ll be using an MVC 3 web application and the new MvcScaffolding – awesomely demonstrated by the genius Steven Sanderson here and here .

If you want to follow this example, these features mean you only need spare 5 minutes of your time.

Setup

Let’s do it:

1. Create a new MVC 3 web application:

a. Razor view engine

b. Internet application

2. Create a domain model

a. Add a “HealthFood” class to the “Models” folder – like so

public class HealthFood

{

public virtual int Id { get; set; }

public virtual string Name { get; set; }

}

Above: HealthFood – our domain model (virtual properties for ORM)

3. NuGet: Install-Package MvcScaffolding

4. NuGet: Scaffold Controller HealthFood

5. Run the application after adding a link to the HealthFood controller. Then add a few entries

<li>@Html.ActionLink("Home", "Index", "Home")</li>

<li>@Html.ActionLink("About", "About", "Home")</li>

<li>@Html.ActionLink("Health Foods", "Index", "HealthFood")</li>

</ul>

Above: A link to the HealthFood controller in _Layout.cshtml

Above: A few HealthFoods added to the system

Rain-Check

With a system all set, a few entries added – let’s check what the default behaviour is for viewing an object – the edit action.

public ActionResult Edit(int id)

{

HealthFood p = context.HealthFoods.Single(x => x.Id == id);

return View(p);

}

So, what happens is that we take the Id from the posted form values and query our “repository”. We then return the HealthFood to the view.

What if I want to model bind directly to the HealthFood – what if I’ve got many examples of this scenario – I can save a lot of code and make things DRY – and even testable – if I had a reason for testing controllers (rarely that I ever do).

AutoLoad Model Binder

Creating a model binder to retrieve persistent entities is actually fairly easy in this scenario. I’ve avoided the bullet of generic repositories, but I will be adding this feature soon.

Here’s the model binder which I’ve added to a new folder in the project called “ModelBinders”.

public class AutoLoadModelBinder : DefaultModelBinder

{

public override object BindModel(ControllerContext controllerContext, ModelBindingContext bindingContext)

{

var typeBeingBoundTo = bindingContext.ModelType;

var valueKey = bindingContext.ModelName;

var rawValue = bindingContext.ValueProvider.GetValue(valueKey);

var entityId = Convert.ToInt32(rawValue.RawValue);

//TODO - tied to implementation details - I know

var dataContext = new AutoLoadModelBinderExampleContext();

var allItemsOfType = dataContext.Set(typeBeingBoundTo);

var entityBeingBoundTo = allItemsOfType.Find(new object[] {entityId});

return entityBeingBoundTo;

}

Remember the requirement where I wanted an opt-in scheme – so this model binder doesn’t apply by default. Well, to make it work this way, we apply it to our action parameter like so:

public ViewResult Details([ModelBinder((typeof(AutoLoadModelBinder)))]HealthFood id)

{

return View(id);

}

Testing Out the AutoLoad Model Binder

If you now run the app again and navigate to the details page for a HealthFood – it works. It still works. Hence, the model binder works, and it’s an opt-in scheme….

…but the declaration is ugly. It’s clunky - it makes the controller look horrible if I’m honest. What can we do about that?

Well, I figured, I could just extend the ModelBinder attribute, rename it to AutoLoad and hard code the AutoLoadModelBinder into its constructor. But ReSharper doesn’t like that. The compiler doesn’t like that…I don’t’ like that.

So I check out the metadata for the ModelBinder class and I see that this cheeky boy, whilst sealed and having none of it, inherits the “CustomModelBinderAttribute” class. Awesome – game on.

Improving the AutoLoad ModelBinder’s Usage

With this new information – the “CustomModelBinderAttribute” - a class I never knew existed – I created the following:

public class AutoLoadAttribute : CustomModelBinderAttribute

{

public override IModelBinder GetBinder()

{

return new AutoLoadModelBinder();

}

I put this class in the “ModelBinders” folder, but you can stick it anywhere you like (no offence).

All it does is ensure that the model binder used is my AutoLoadModelBinder.

Testing out the AutoLoad Attribute

Now we have the “AutoLoad” attribute. We can simplify this:

([ModelBinder(typeof(AutoLoadModelBinder))] HealthFood id)

…to this:

([AutoLoad]HealthFood id)

Sanity Check

So let’s test it out. What happens when we head to the details page for a HealthFood now?

Above: AutoLoad fantastico – elegant and effective

As expected (read: “hoped”) it still works.

Conclusion

Model binding to persistence entities (auto loading as I seem to be calling it) can help to make your controllers look a lot cleaner and be a lot more DRY – by not repeating calls to a repository – and even removing references to repositories altogether. If you have attribute-based web transactions for your ORM tool’s sessions and transactions, then those controllers really can go on a diet.

But let’s be aware that in this example I tied my model binder to the entity framework DbContext. What would be awesome is to make use of MVC 3’s DependencyResolver and the repository pattern to make this binder ORM-agnostic. So whatever repository the DependecyResolver registers, it is that which get’s queried.

What about nested entities, many-to-many relationships in scenarios where we create and update records? The attribute and the model binder still have a lot to incorporate before I’m happy.

I will be augmenting and improving the behaviour of the [AutoLoad] in coming posts.

Also, did you notice how cool the MvcScaffolding was in this scenario and how it plays nicely with NuGet? Keep up the good work Steven Sanderson and the rest of the Web Platform Team.