Blog marking: Quality AJAX Resources and Tutorials
SharepointBlog has an interesting post on how to use .NET custom attributes for Release Documentation. I was discussing with sendhil and sendhil shared the idea that whenever we have a TODO item in our code, we should actually use something like this and generate the backlog, so that we will always have an updated backlog.
I was reading the SPRING.NET Q&A session in the InfoQ Website and found a Simple explaination for Dependency Injection.
What is Dependency Injection and Why should .NET Developers care about it?
Dependency Injection is actually a very simple concept. When you look at a typical application, you will see there are many dependencies between objects. Presentation layer objects will depend on service layer objects, which will themselves depend on other service objects and data access objects, etc. Within a running application there are many interdependent objects that are "wired" together.
The naïve way to obtain a dependency is to create it directly by calling its constructor. This works, but it has a number of problems:
· Classes become difficult to test in isolation,
· It is impossible to change which dependent class to use without modifying the code that created it, etc.
Most of these problems can be solved by using some kind of a configurable Factory, Service Locator or Registry to create or look up an object. This approach, which we could call Dependency Lookup, can work very well if implemented correctly, but it introduces a dependency on the Factory, Service Locator or Registry itself, which is often not desirable. It also requires more work than Dependency Injection.
On the other hand, Dependency Injection implies that an object’s dependencies will be "injected" by external means. There is no need for an object to look up anything – it simply declares private fields for its dependencies and allows for them to be provided externally, either via a constructor argument or via a property setter. This makes objects very clean and reusable, and if dependencies are declared in terms of interfaces instead of specific classes, it also makes them very easy to unit test.
If you think about it, there is nothing new about Dependency Injection per se. Whenever you set a Connection property of an IDbCommand instance, or a Menu property of a Form instance, or when you pass a Socket instance as an argument to a NetworkStream constructor, you are manually injecting dependencies. I could find similar examples in older technologies as well, such as VB6 or COM.
However, what made Dependency Injection so popular in the recent years is the rise of lightweight containers such as Spring, Pico and HiveMind in Java, and Spring.NET, Castle, and more recently Microsoft’s ObjectBuilder in .NET. These containers allow you to configure object-wiring rules within your application and based on those rules they will create and wire your application’s objects together, providing you with automatic dependency injection. The ways in which different containers allow you to specify object-wiring rules are different, but the ultimate goal and the end result are usually the same.
There are other benefits which containers have to offer as well. Because they know about all the objects they are managing, it is very easy to manage objects in a running application. I’m not sure about other containers, but Spring and Spring.NET also offer hooks that allow you to execute custom logic in different states of an object’s lifecycle, which is very useful at times.
Sendhil has shared his experience in implementing WCF.
We started using WCF in our project recently.
The vision (read architecture) was good when people (the likes of Don Box) were speaking about WCF.
However after using it and getting my hands dirty, I really doubt if the implementation really lives up the expectation set by the vision.
There has been a quite a few issues with WCF, but the one I ran into yesterday was proof that Microsoft has compromised on people aspects (atleast at the developer level). The vision still seems to be good. People like myself are getting into Microsoft development teams (Core teams, I believe WCF is one of the core elements of the Framework). This is what I saw yesterday.
I wanted to write my own ServiceHost so as to apply the WCF configuration myself. I was rather wild when I learned that configSource attribute is not supported on any of the WCF configuration sections. And if I really had to load the configuration from an external source I had to reinvent the whole WCF configuration approach myself. Source: http://blogs.msdn.com/drnick/archive/2006/12/04/overriding-the-default-configuration-file.aspx. Well that’s not what I wanted to blog about.
The ServiceHost class contructor (or one of it’s base class’s) call ApplyConfiguration which happens to be a virtual method. Oops, constructors calling virtual methods, I thought that was not encouraged. I decided to google on this and found that I was right. The good folks from Microsoft have written about this here and here. In fact they found it reasonable to include it as a FxCop rule as said here. But only for folks outside of Microsoft may be. They went ahead and violated their own rule. The irony is that it slipped out of the design, design reviews, development, development reviews and testing. ServiceHost happens to be one of the core classes of WCF.
The bottomline is that Microsoft is compromising on the process (the fact that this one slipped thru all the reviews and testing) for getting stuff out early, as well as people. Not so good news.
- Building Domain Knowledge
- The Ubiquitous Language
- Model Driven Design
- Refactoring Toward Deeper Insight
- Preserving Model Integrity