Software Rockstar

ScottGu  just made available a free downloadable eBook in PDF format as well as a simple and easy-to-understand sample project called Nerddinner.

The eBook is actually a chapter from his upcoming book on MVC, but it is an end-to-end tutorial that walks through building a small but complete ASP.NET MVC application from scratch.

Download eBook.

Download Nerddinner sample code.

Buy ASP.NET MVC 1.0 Book at Amazon.com. 

If you do decide to read this book, please do not forget to share your thoughts with me.

In the last couple of years I have noticed a steadily growing interest in the .NET community around the Inversion of Control (IoC) and Dependency Injection (DI) patterns.  This is partly due to the fact that a number of excellent frameworks have emerged and gained popularity that allow us to use these designs in our applications relatively painlessly.  One such framework is the open source Castle Project.  In my opinion Castle is the best implementation of IoC and DI among many others that I have come across including Spring.NET, NInject, and ObjectBuilder.  This is however my opinion; which framework you use largely depends upon your requirements and your preferences.

If you are just getting started with Castle or are curious about why the heck one should use IoC and DI, I strongly suggest you check out the 3-part article series by Simone Busoli.  I just came across these articles and I can’t stress enough how well they are written.

The Interface Segregation Principle (ISP) deals with cohesion and is closely related to the Single Responsibility Principle (SRP). In Uncle Bob’s terms, the ISP states that:

Clients should not be forced to depend on methods that they do not use.

In other words, this principle states that if a class performs multiple functions that may be used by different client classes, then those functions should be seperated out into different interfaces according to their usage.

The idea behind this principle is to confine the aount of rework to only clients that use a certain interface, should the interface of a depended-upon class changes.

Windows Workflow Foundation (WF) is Microsoft’s latest platform for building workflow-enabled applications. Along with Windows Presentation Foundation (WPF) and Windows Communication Foundation (WCF), WF is part of the WinFX platform, now officially named as .NET Framework 3.0.

While workflow capability has been available to developers using BizTalk Server and other third-party products, WF provides a single platform and programming model for Microsoft products (e.g. Office) and non-Microsoft products (developed using .NET) making workflow more of a mainstream paradigm.

In it’s simplest form, the workflow-based programming model consists of a set of business activities along with repetition and conditional logic that is modelled using some sort of a user interface. At run-time, the conditionals are evaluated and activities are executed based on the modelled workflow. If you have ever created a SQL Server DTS or SSIS package then you are already familiar with workflow-based programming model.

Some of the advantages of workflow-based programming include durability, transparency, and tolerance to dynamic change. It allows for rule-based programming and supports a declarative model which allows for easy modelling and modification of business processes.

WF nicely integrates into Visual Studio offering a rich design-time and debugging environment. Workflows can be hosted by any .NET executable assemblies including Win Forms and ASP.NET applications. WF comes with an array of built-in activities e.g. Code, Delay, Invoke, Throw, Suspend, etc., but the best part is that custom activities can be created as simply as deriving from the Activity base class and overriding the Execute method. Even composite activities can be created providing a rich and extensible programming model.

The Activity Framework in WF provides several of out-of-the-box services such as transactions, compensation, serialization, etc. Other services can be added as desired. For example, by default workflows are persisted using XAML, but if needed custom serialization may be added.

In conclusion, WF provides a very rich and highly extensible workflow-based programming model. With the passage of time we shall witness more and more Microsoft and non-Microsoft products using the WF to build and enhance applications that could use workflow functionality in new and innovative ways. As they say in French, the best is yet to come!