[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
When dealing with POCOs, a common scenario is to track changes. Look at this interface:
|
1 2 3 4 5 6 7 8 9 |
namespace DirtyObjects { interface IView { string Name { set;get;} int Weight { set;get;} bool Modified { set;get;} } } |
It is the interface of a simple view class containing the name and weight of a product. The Modified property is used to track whether the object has changed its value, so that we know if we should save the object after it has been edited.
A typical implementation might look like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
namespace DirtyObjects { class MyCumbersomeView : IView { private string name; private int weight; private bool modified = false; public int Weight { get { return weight; } set { if (weight != value) { weight = value; modified = true; } } } public string Name { get { return name; } set { if (name != value) { name = value; modified = true; } } } public bool Modified { get { return modified; } set { modified = value; } } } } |
It can be seen above that modified is set to true if a change is detected whenever a setter is called. This is pretty straightforward, yet it seems that an annoying pattern emerges when there is more than a few properties.
How can we then get rid of all the boilerplate code, all the noisy bits in between? Well, there is a way: by using Castle‘s
DynamicProxy and a simple technique from aspect oriented programming called method interception. Read on to see an example.
Read more
A funny thing in programming, captured in a term by Martin Fowler and Eric Evans, is fluent interface.
Explained shortly, it is a style in programming which attempts to make your programs (or parts thereof) resemble sentences as you could (but probably seldomly would) have pronounced them in a fairly understandable human language.
It is easier in dynamic languages like Ruby, but it is still possible in a staticly bound world like that of C# – and it is often a fun challenge to design your utility classes or domain logic to use fluent interface! Moreover, it has a legitimate use in implementing internal domain-specific languages because of its resemblance to human language.
A small example of a list converter class using some kind of fluent interface can be seen if you carry on reading below.
Read more