I just finished my very first web forms project. Yes it's really true. I have never had any real hands on web forms before. When I started programming web stuff in ASP.NET I went directly from PHP5 to ASP.NET MVC Preview 2.
When I was working with PHP, I used the joomla open source CMS, which implements the MVC design pattern. Yes, MVC is actually a design pattern rather than something new fancy stuff that Microsoft invented. Microsoft, however, did what they do best; Go all the way with their ideas which resulted in the fabulous ASP.NET MVC framework.
Anyway, what I realized, while working with the classic web forms project, was that it's quite possible to implement the MVC design pattern even though there's nothing "MVC" visible anywhere.
Consider the following as your controller:
protected void Page_Load(object sender, EventArgs e)
{
if (IsPostBack)
{
PersonRepository pR = new PersonRepository();
pR.addPerson(textfield.Value);
Response.Redirect("~/Default.aspx", true);
}
}
The controller's job is to take values from the view, and hand them on to the Model which does the actual business logic. The snippet above, takes a string from a text input field, and parses it in a repository. Then redirects the user to Default.aspx.
In the snippet above, the PersonRepository represents the Model because it is domain specific. The Model does not know anything about the view.
Using a domain driven design, is essential for us to gain the MVC pattern. But if we do so, we are rewarded instantly when we want to create unit tests for all of this. The ASP.NET MVC framework however, is a lot easier to unit test than web forms.
For me, the major difference between web forms and ASP.NET MVC, is that the horrible runat="server" tags are gone!
Praise the lord!
Table of contents
- Introduction
- Setting the stage
- Defining the initial user story
- Limiting, and splitting the user story
- Finalizing the user stories
- Organizing user stories
- Summary
Introduction
I think I speak on behalf of almost any software developer, when I state that estimating a piece of software is hard. I dare you to count the times, where someone has asked you the question "How long time will it take?".
This very question is really unfair, because it undermines everything we stand for as software developers. We want to know all the details, we need to think in patterns - there are very often too many unknown factors when we are required to answer that question.
For a long time I have been looking for a alternativ method, to somehow measure the size of a given feature, which ultimately could give me a clue on how much time was needed to implementent that feature.
I have tried (and failed), and heard of even more, different approaches ... everything from using several hours talking about a tiny feature, to not doing anything at all. None of theese have worked out very well.
Recently i read a book called "Agile Estimating and Planning" by Mike Cohn, a part of the "Robert C. Martin Series".
This book took a different angle on estimating software, which really opened my eyes.
When reading this book, everything seemed so clear, straight forward and logical that i could not wait to finish the book and implement it on my team at work.
We have been working with this method for some time now, and so far it's working really well - which is why I want to share how I got started.
There are many details, including which tools I use, that I wish to share, I will post three blog posts covering the following:
- Defining user stories
- Planning poker
- Keeping it running
Setting the stage
Before I start out, it's relevant to mention that the team is working according to
SCRUM with me as scrum-master and, on some projects, the product owner.
We work in 14-day sprints, with the following marks:
| Day 1 (monday) | Team chooses estimated user stories from the product backlog, which they commit to finish within this sprint. Afterwards, I reorganize the productbacklog. The team get to work on the selected user stories the same day. |
| Day 2 - 7 | Team work on selected user stories. |
| Day 8 (monday) | Team estimates next user stories in the product backlog. |
| Day 9 - 14 | Team work on selected user stories. |
| GOTO Day 1 ( Wow! Good old batch-file label call ) |
I will not get into details on how SCRUM works. All I can say, is that it works ;)
Defining the initial user story
When we are going to define our user stories, you must have done your homework properly. And by homework, I mean talk to customers, interns and everyone else who might have something to say about the software features. Lets say we are developing a website for a client, we want to make sure that we actually understand what the client wants, before we start writing any code.
User stories always describes the functionality which the end users experience. A template for such a story could be:
"As a <type of user> I want to <description of functionality> because <business value>"
You might want to change this template to your needs. For instance, much work on a large scale project includes making internal help methods and classes which can result in pretty funky user stories.
Lets say the website requre login for their customers. A initial user story for this, could be:
"As a customer, I want to be able to log into my account bacause I want to buy stuff"
This is pretty easy, and most people are not in doubt of what i mean when I present the initial user story for them. And most important, we have isolated a specific part of the whole project.
Limiting, and splitting the user story.
Lets continue the user story example from above. We want the website to block the customer if the customer types a wrong password three times in a row. We also want the website to give the customer some readable messages if he is doing something wrong.
This meens we have to split the user story into more specific stories. I have found the following two ways of splitting, satisfying:
- Split the story by business-logic speration.
- Split the story by database database seperation.
Splitting it by business logic, meens that we need to identify where the functionality splits naturally. If we do not split it, it oftens ends up in a seperation by code anyway. So you need to try to identify this natural seperation.
Splitting by database is done by looking at the database tables, fields stored procedures etc. which the user story is using.
Finalizing the user stories
Using theese split methods, our initial user story:
"As a customer, I want to be able to log into my account bacause I want to buy stuff."
Could end up as theese stories:
"As a customer, I need to be presented with a readable error message if I type my password is wrong."
"As a customer, I want to see how many login attempts I have left, if I type my password wrong."
"As a customer, I want to be notified if my account has been blocked, if I type my password wrong three times in a row."
"As a customer, I need to be redirected to my personal frontpage if my login credentials are correct."
Organizing user stories
Organizing the user stories can me done in many different ways. I've tried different programs, but the one that i found most useful, is actually Microsoft OneNote. OneNote does not pull all kinds of constrains down over your head. It's in general a very friendly program. However, because it's so friendly you really need to keep all order by your self. OneNote documents easily gets messy.
OneNote lets you easily create a table with user stories, story point (Explained in part 2) and other relevant info. It also lets you move priorities around very easily. I might do a webcast video on this topic, to show you how I manage all project data in OneNote.
Another reason why I use OneNote is that it's pretty. My development team has a computer hooked up to a big screen tv in the team room, and it's very good for all the team members to see how everything is organized. And if the team decides to change some priorities, they can see that it's done rigth away.
I keep two seperate user story lists, besides my product backlog.
- Estimated and prioritized user stories
- Prioritized list of Initial user stories, which is to be estimated and re-prioritized.
Summary
Before we can do any estimating at all, we need to break everything down to user stories. Using user stories is a good way to limit and contain piece of functionality. And most important, it keeps focus on the features that our customer want. The worst thing that can happen in a software project, is that we build the wrong software. Applying user stories helps us keep focus on what we really need to do.
In my next post, I will explain how we begin to estimate the user stories and how we apply them to our development team.
Until then, happy coding :)
Oh joy!
When I first read ScottGu's blog about the MVC beta release, I could not wait to give the refactored modelbinding a go. Modelbinding finally seemed to be fully implemented and looked like something that could really cut of some repetitive work when working with form-heavy web sites.
To rapidly sum up what model bind does, consider the following code snippet:
Putting the type "Customer" as a parameter of my action result, invokes data mapping from my form to my object. If you want to know more about model binding, you can check out bradygaster.com's fine model binding example.
Oh no!
I gave the modelbinding a try on a new clean MVC project that I created in visual studio 2008, and everything worked perfect. I could not get my arms down!
Then the trouble began. I had forgot everything about my use of Unity. Unity creates a certain level of looseness towards instantiating new business objects, however my MVC project only knows of the interface of any business object and not the implementation of the interface.
This made my try weird stuff like
This actually compiles, but the ICustomer is, quite natually, null as the MVC controller factory does not know anything of how to instantiate any implementation of ICustomer.
At this point, I was pretty much crying!
Well, ok!
To my luck, the MVC mapping sequence is available through the updateModel method, which meens the following will work:
Summary
Dependency injection gives you lots of benifits and lets you use your constructor parameters promiscuously. How ever, when planning a MVC project you might want to reconsider how to aproach this issue.
The UpdateModel method works fine for me, but it might not work for you.