ÖreDev Day 4 – Afternoon

· November 5, 2009

I’m still feeling a bit exhausted from Dan North’s previous talk, but now it’s time for some more down-to-earth coding topics.

Putting the M of ASP.NET MVC with Scott Allen

Scott Allen started by discussing the role of the model in ASP.NET MVC and its intended audience:

  • Business objects can be useful, especially when building wrappers around SQL Management Studio, but they may not always serve the best purpose in MVC applications.
  • The model often has to cater to both the view and the business logic. To address this, Scott recommends creating a view model. While this may lead to many classes, it ensures that each class has a well-defined responsibility.
  • You can define an interface to specify which properties should be bound when using TryUpdateModel<T>.
  • Instead of using IModelBinder for model binding, which can be cumbersome, override OnModelUpdated on the default model binder and only add modifications where necessary. This is a great tip! Remember to register the binders in Application_Start.
  • The controller’s primary role is to orchestrate the application, not to bind the model. Controllers should focus on managing the application’s parts.
  • In ASP.NET MVC, you can utilize DataAnnotations for validation.
  • Additionally, EnableClientSideValidation allows you to create JavaScript validation from your server-side validation.

Scott provided a wealth of information, and I learned a lot from his session. Thanks, Scott!

Specification Workshops

The next session was focused on BDD, which I find quite interesting. The speaker, Gojko Adzic, was passionate and engaging.

Some key points from the workshop:

  • Viewing code from the customer’s perspective can be akin to examining something created by Mr. Klingon.
  • The book How Experts Think was highlighted as one of the most significant reads.
  • Asking “Why?” frequently in software projects helps clarify requirements and avoid solutions to unknown problems. An example discussed involved a request for a printout to be typed into another system, highlighting the need for clearer understanding.
  • On-site customer representation should be seen as a role rather than a single omniscient individual.
  • Collaboration on specifications is crucial. Business people, testers, and developers should work together to drive the specifications through discussions and examples.
  • Example-writing workshops or specification workshops are useful methods for driving specifications. The process involves:
    • Choosing a story
    • Introducing and explaining it with examples
    • Allowing questions and additional example suggestions
    • Discussing until there’s confidence that enough examples are provided to begin work

This approach fosters shared domain knowledge and evolves the ubiquitous language.

Overall, the workshop was fantastic! Thanks, Gojko, for the valuable insights.

Twitter, Facebook