MS Application Block - UIP v.2.0

The artifacts reusability in software development is considered as one of the ways to maximize ROI. One way to utilize this idea is to adopt practices and patterns. That's why .NET developers may benefit from using MS Application Blocks. The one that I recently used was User Interface Process Application Block - Version 2.0. The code block comes with an installer, pdf documentation and quick start samples.
UIP has the following features

Web session resume

Web session transfer

Reuse of code between application types

Development of discrete tasks

Storage of state in state persistence providers

Expanded navigation management

Additional state persistence providers

Layout managers

Enable back-button support

Usability enhancements

In brief UIP provide functionality to effectively separate the business logic from the user interface. It allows the developers to develop complex user interfaces by reducing the time for writing workflow process management code. There is support for WinForms and Web based applications. However Web User Controls are not supported directly /not considered as a view/. The workflow process and navigation is easily re-configured by changing the settings into the config file without need to refactor your code.

My first trial was to migrate Web .NET based application to use UIP block. The application / a billing system / was pretty small / 10 Web Forms, about 15 Web User controls/. The application design proposed stated that there are presentation layer and data access layer. However the presentation layer performed different activities, which may not be considered as strict data presentation or user interaction. Actually that was activities which maintained the integrity of the tasks performed by the user, e.g. workflow processing.

After adopting UIP code block into my application the design appeared to be more abstract and clear. The Presentation layer now performs activities strictly related to data rendering and user interactions. UIP controller stands between the presentation and data access layers. It is the component which performs workflow process management and dealing with the integrity of the user performed tasks. The presentation layer now makes calls to the UIP controller which in turn makes calls to the data access layer.
After these changes the workflow process and navigation may be reconfigured to meet the user requirements without recompilation
The time to learn using UIP code block was pretty short and it worthed.

Mock objects ?

Mock objects is an approach for testing interactions between components by faking the behaviour of the components from external libraries.
They are must have knowledge if one is trying to utilize TDD methodology.
Some of the wide spread statements about the reasons to use mock objects are:

They are easily created and set up.

Usually they work very fast comparing to the original implementations

They are deterministic.

Testing with mock objects improves domain code by preserving encapsulation, reducing global dependencies and clarifying the interactions between classes. I am impressed by this concept, however using mock objects raises some additional problems. As with any unit testing, there is always a risk that a mock object might contain errors / actually this threat is valid for unit testing as a whole /. In some cases it is difficult to create mock objects that represent types in a complex library.
However having mock objects in our toolset is vital for writing elegant and useful unit tests


There are some .NET mock object libraries and the one I like the most is NMock

VSNUnit

VSNUnit is a very useful NUnit related tool. It integrates NUnit into the VS environment and makes unit testing activities in VS easier and faster - you do not have to leave the working environment while testing. The developer receives test results integrated with his source code.
I really like it. There are some problems that should be fixed / it's beta3, yet / , but anyway I like the idea.
The tool is open source and may be obtained from here

First steps in TDD

My first impression from the Test Driven Development papers was negative. I was little bit suspicious.
I wondered why should I write so much code that is actually out of the project scope. Why should I spent so much time to think about tests before even write a line of useful code. Is this a practically inspired and efficient methodology or just a kind of yeasty theoretical thesis.
I wondered if this methodology is meaningless, why is this world-wide craze about TDD happening . This questions and the world-wide craze forced me to try using the TDD approach in a couple of simple projects.
I was suprised when I saw TDD as a real practically inspired methodology a result these are the advantages as I see them:

• TDD is forcing me to write clean and elegant code.

TDD forced my self to write my code in a way to maximize usability. As a result my code is clean,elegant,easier to understand and function exactly as I presume

• TDD forces my developing effort to focus over the project scope.

First you have to write down the list of tests that you should implement in order to meet functional requirements.
Then when you have the tests implemented and your code have passed them, you already have a code that meets the functional requirements.

• TDD gives me a confidence about my past work.

Before TDD when I sit down and start coding it takes a lot of time to investigate if a broke something. Now I know - hit RUN and wait the green light. It is very useful when I am in a hurry

To be continued ...

My frist blog post

Hope my blogging activity will be not only a waste of time, but somehow usefull ....