I’m still feeling a bit exhausted from the last Dan North talk. Now we will have some more down-to-earth code stuff.
Putting the M of ASP.NET MVC with Scott Allen
Scott started off by defining the purpose of the model is, who does it serve?
- Business objects are great if you build a wrapper on SQL Management Studio ;)
- The model can be found serving two master – both the view and the business logic.
- The answer to the above is too create a view model. But that can give you a lot of classes. I (and Scott) think that will be worth it – because every class now have a well defined responsibility.
- Cool – you can define an interface that decides what properties to bind when using TryUpdateModel<T>
- Don’t use IModelBinder to bind your own models because you’ll have to write much code. Instead override OnModelUpdated on the default model binder and add only to things that differs from the default binding… Great tip! The binders are to be registered in Application_Start.
- The controller should not really bind the model – it’s not it’s responsible for that stuff. A controller should only orchestrate the application parts
- In ASP.NET MVC we’ll have the possibility to use DataAnnotations
- Cool – EnableClientSideValidation to create JavaScript validation from your server side validation
Yeah I learned a lot of things here. Thanks Scott!
Specification workshops
From the program this should be on BDD which I like, so I hope that will learn more on it. The speaker is very passionate and fun.
Customer looking at code is as looking of things produced by www.mrklingon.org
“How experts think” was dropped as “the most important book I’ve read.
“I am the only one in the room that have hade the privilege to be bombed by a B2-bomber…” Eeeeh.
Ask the question Why? more often in software projects.
Requirements are often given as a solution to an unknown problem. A story of people requesting a printout to be able to type into another system made that point very clear.
On-site customer is a ROLE not a single know-it-all-person. Such a person doesn’t exists.
Collaborate on specifications – business people, test, developers. Do it everybody together.
Do it by discussing examples – you don’t need to write it down but use to drive the specifications. Example writing workshops or Specification workshop (or any name that scare them enough to come)
Run the workshop
- Choose a story
- Introduce it, explain with examples
- Let people ask question and suggest other examples
- Discuss until everyone is confident that we have enough examples to start working
This leads to a shared domain knowledge and evolving the ubiquitous language
This was great! Thanks Gojko.