[this post is outdated – too much has happened since the first CTP]
In this part of the ASP.NET MVC tutorial we will create our own controller factory which will use Windsor to resolve dependencies and supply each controller with a NHaml view factory. Then we will create some simple views and watch the whole thing in the web browser.
Read more
[this post is outdated – too much has happened since the first CTP]
This is the first post in a series of at least four about ASP.NET MVC, which I am planning. The series will show a way to build a nifty web site with a tidy, sound, and scalable architecture. ASP.NET MVC will be used to structure the web site, Castle ActiveRecord will be used for persistence, Castle Windsor for dependency injection, NUnit and NMock for testing, NHaml for the views, and principles from agile, domain-driven design, and test-driven development will be used. The series assumes that you want to use the model-view-controller pattern, so I will not try to convince you that it is a great way to structure a web site 🙂 – even though it is, and currently in my opinion the only sane way to make websites when they contain more than one page…
ASP.NET MVC is a part of the ASP.NET 3.5 Extensions, which is currently only available as a preview. Thus, the details might turn out to be a little off, but still most of the stuff we go through here will apply.
As this is the first post in the series, we will start out by creating a the solution and the project structure – just to get going.
Read more
UPDATE: This post is pretty old. Please don’t use XML to configure Windsor, unless you’re aware of the nifty fluent registration API, but you absolutely need the runtime-flexibility that XML can offer.
A great pattern in software architecture is dependency injection (DI). It is a classical pattern apparently, but it seems to have become very popular again in TDD circles because of its obvious positive impact on testability. Moreover, I believe it is a healthy architectural exercise to structure your code to support DI, because it enforces separation of concerns.
Dependency injection can be explained like this: if X requires a Y to do its work, X does not create the Y by itself, it is given a Y to use. Thus, DI is an example of inversion of control (IoC), which is a fancy term for whenever you pass something for someone to call functions on.
In the following post, I will give a short example on how to practice DI using the Windsor IoC container.
Read more