Links About .Net Framework Unified Transaction Programming Model

.Net framework 2.0 introduced a unified programming model for transaction handling. It greatly simplifies the responsiblity on the consumer code for achieving the transaction. While, I was trying to understand this new programming model, I could not find enough blog posts or tutorials. I came across few blog posts that were helpful to understand the basics. Some of the links were shared by my friend. I am sharing those links for anyone who is interested in knowing about it.

Very important links
Transactions in the .NET 2.0 Framework
Very important blog entries on System.Transactions by MarkJen
Introducing System.Transactions in the .NET Framework 2.0
Volatile Resource Managers in .NET Bring Transactions to the Common Type System.Transactions: Implement Your Own Resource Manager

MSDN References
Implementing a Resource Manager
Writing a Transactional Application
Transaction Management in Windows

Other links
System.Transactions and ADO.NET 2.0
Writing a resource manager for System.Transactions
System.Transactions and ADO.NET 2.0
A Quick Primer on System.Transactions
What is System.Transactions?
http://weblogs.asp.net/vlele/archive/2004/11/19/266223.aspx
http://blogs.msdn.com/adonet/archive/2008/03/26/extending-lightweight-transactions-in-sqlclient.aspx

Other Transactionable Resource Managers
Enhance Your Apps With File System Transactions
Windows Vista - Introducing TxR in C# (Part 1)
Windows Vista - Introducing TxR in C# (Part 2)
Windows Vista - Introducing TxF in C# (part 3) - CreateFileTransacted demo
What should I think about when using transactions with the file system?



CodeProject

Wrap finalizer code in appropriate try-catch block

What would happen if the finalizer thread encounters an unhandled exception? Predict the output of the below program:

An unhandled exception on the finalizer thread brings the complete process down. Consider wrapping the finalizer code into an appropriate try-catch block and let only the unavoidable exceptions to escape and bring the process down.
CodeProject

Solution to Programming Quiz: Populating stream with unique random numbers

The generator and the consuming code is as below:


Reader is requested to provide comment if it feels that the above can be made more efficient and has better algorithm than what is shown here.

CodeProject

Programming Quiz: Populating stream with unique random numbers

Create a class which populates a stream with k unique random numbers between 0 to max - 1 in an efficient ( No Space vs Speed tradeoff ) manner.

Below are variables and should be the input to the algorithm:
stream: Stream
k: int
max: int

CodeProject

Pseudo .Net Custom Attributes

Pseudo custom attributes are custom attributes but are treated by the compiler differently than other custom attributes. The storage and retrieval mechanism is different than the other custom attributes. This is done because the pseudo custom attributes are frequently used and it requires space-efficient storage and faster check at runtime. Below are some points which are worth understanding about pseudo attributes:

1. Pseudo attributes are laid out in the assembly metadata differently than the other custom attributes. For e.g. Presence of [Serializable] attribute on a type is laid out in the assembly metadata by making a bit on or off. [Serializable] attribute is the one of the most common pseudo custom attributes and it is stored in this manner for the purpose of storage and retrieval efficiency. They are either laid out as bit field or a flag which is unlike other custom attributes that are laid out as blobs.
2. Some of the Pseudo Custom attributes are not reported by the overloads of Type.GetCustomAttributes overloaded functions.
   For e.g. Presence of [StructLayout] attribute is not reported by the GetCustomAttributes methods on the Type class.

The above points helps when you are developing an application which involves heavy reading of metadata using reflection.

CodeProject

Dependency Injection

Every software entity is dependent on zero, one or more software entities for its functioning and providing its services to the consumer (calling entity). Dependency Injection is a method of injecting the dependencies in the serving class by either the caller or an IoC container.

Instead of the serving component creating dependencies by its own, it is the caller or the IoC container which is responsible for creating those dependencies and injecting it into the component.

Ways of declaring dependencies

Component declares its dependencies using one or more of the methods of declaring dependencies. Below are the ways a component can declare its dependencies:

1. Constructor Injection: The component declares the dependencies as a parameter to the constructor. All the mandatory dependencies can be captured in the constructor as read-only dependencies. Optional dependencies can be captured by providing the parameterized constructors.
2. Parameter Injection: To provide dynamic configuration and modifications of dependencies at runtime, parameter injection can be used. Usually parameter injection is used for optional dependencies.
3. Method Injection: If the dependency is required only for a limited scope i.e. only for a specific method in the component then method injection becomes an appropriate choice. In this type of injection, dependency is injected as a parameter of a method.

Benefits

1. Interface Driven Development: Dependencies are declared using interfaces or abstract classes. Varying implementation of the interfaces can be used. This promotes extensible and flexible design.
2. Loose Coupling: Loose coupling is achieved by dependency inversion. The component depends on the interface and any implementation of the interface can be substituted for the dependency.
3. Parallel Development: The component does not require that its dependencies are already in place and implemented. It only requires an interface of the dependent component. Infrastructure team can publish well thought and properly designed interfaces to the application team. Application team can start developing business logic without waiting for the actual implementation of the dependency to available.
4. Promotes Unit Testing: A UUT (Unit Under Test) should be isolated from the consequences its dependencies to get the maximum benefit of unit testing. Dependency Injection provides a way to isolate the unit under test by providing stubs or mocks for the dependencies.
5. Configurability: Using IoC container declarative and programmatic configurability can be achieved. Declarative configuration supported by IoC container can be used to configure what dependencies get injected in the component. Application can be configured declaratively without the need for compilation.
6. Adherence to Single Responsibility Principle: It smells of breaking a SRP (Single Responsibility Principle) when the component declares more than three mandatory dependencies. The smell may denote a problem where the component has more than multiple responsibilities or lack of cohesion. This type of smell can be mitigated by applying refactoring to introduce new type and moving some of the unrelated responsibility to new type.

Limitations

1. Disclosing Internals: The component reveals its internals by declaring dependencies. The calling component has to have knowledge of creating the dependencies and injecting in the server component.
2. Dependency on IoC Container: It creates a dependency on IoC container. It changes the way how you design your classes.
3. Over Engineering: If not properly thought, Dependency Injection and use of IoC container may lead to designs which are over engineered. A judgment call is to be made whether such flexibility of declarative configurability is required or not.

Decorator Pattern in .Net Framework

Decorator Pattern is a structural pattern. It is used to attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Decorator pattern is used in .Net. The following collection classes are the decorators of the ArrayList class:

1. SyncArrayList: This denotes a synchronized arraylist which can be used multithreading scenario. This arraylist is to be used when multiple threads are to modify a single instance of arraylist.


2. FixedSizeArrayList: This denotes a fixed size arraylist. The size of the array list cannot be changed. Elements cannot be added and removed. Existing elements can be replaced.


3. ReadOnlyArrayList: This denotes a read-only arraylist. Elements cannot be added and removed. Existing elements cannot be replaced.

All the above decorators are defined as following:

private class [Sync/Fixed/ReadOnly]ArrayList : ArrayList

{

internal [Sync/Fixed/ReadOnly]ArrayList(ArrayList arrayList) {...}

}

The above structure is the proof of all the aboved mentioned classes to be a deocorator of the ArrayList class.

All the above deocorators are private and can be instantiated using the static methods provided on ArrayList class:

All the decorators override appropriate virtual methods and adds the additional behavior. Below shows the sample code snippet for the Synchronized arraylist the decorators:

Similarly ReadOnlyArrayList overrides the virtual method of the ArrayList class and throws exception to restrict any modifications in the list.

In a similar manner FixedSizeArrayList overrides the virtual method of the ArrayList class and throws exception to restrict any changes to the size of the list.

This is how the decorator pattern is being used in .net framework. There are possibilities of decorator pattern being used at multiple places in the framework. It can be found out by studying the framework thoroughly and understanding the patterns used in the framework.