Saturday, August 20, 2005
The Case For Code Reuse
This article 'Code Reuse in the Enterprise' states reuse as beyond reusing of code, and I quote:
"... reuse has move beyond 'code reuse' to include a wide range of assets that can be used in multiple applications and projects. An organization's software assets could include any artifact related to the software development life cycle such as code components, Web services, patterns, models, frameworks, architectural guidelines, and process templates"
Yes, and in fact, that is the true value of reuse; not only at the code level, but in the way we go about architecting and designing applications also; The benefits that I see are threefold:
- Increased development speed - as the development team overcomes the initial steep learning curve in adopting any architecture frameworks, it becomes easier for them to 'reuse' these knowledge onto subsequent projects to achieve the same functionalities e.g. security, logging etc. In fact, the .NET Framework is such a case, albeit on a more general and broader context. Enterprises or software vendors can come up with the own frameworks, building on the .NET Framework, customizing it into their context of application. An example of such a framework would be the MS Enterprise Library.
- Product stability - as the frameworks matures over time, reuse will ensure that the functionalities they provide are 'tried-and-tested', making sure bugs and issues are already identified and rectified. This results in lesser-bugs per line of code and yet lesser time for development.
- Consistency and Standardization - As design patterns are applied over and over again across projects, it becomes 2nd nature for developers to adhere to a consistent coding standards, which then forms a de-facto enterprise level coding guideline. This consistency makes it easier for new developers to take over existing projects, and increase the maintainability of the programs. Again, the .NET Framework does a very good work of applying these design patterns that developers building applications on top of the framework finds it easy to adopt knowledge from using one part of the framework onto another part. A good example as highlighted in
'Discover the Design Patterns You're Already Using in the .NET Framework', is the Observer Pattern which is applied throughout the framework, allowing the decoupling of the event source and the event handler. It is consistently used in event handling behind UI triggers, both for Windows and Web applications.
I guess there are more benefits, but these are some that are most striking to me. However, be mindful that reuse is no 'silver bullet' to the software developments woes; overrun projects, late delivery, requirements mismatch etc. Nonetheless, adoption of reuse is necessarily one of the key driver in many of the success stories of software projects.
Saturday, August 13, 2005
Solution for Deployment of Enterprise Library with Builtin Instrumentation
In searching for solutions to the built-in instrumentation within EL, I found the following blogs that are very useful:
In instances where deploying with administrative rights is not an option i.e. externally hosted solutions, the EL must be recompiled to disable the built-in instrumentation via removing certain compiler directives.
this blog explains the steps required to achieve this, and I quote it here for ease of reference:
- Open up the EnterpriseLibrary.sln and modify the Configuration Properties\Build\Conditional Constants of the EnterpriseLibrary.Common project.
- Remove the USEWMI;USEEVENTLOG;USEPERFORMANCECOUNTER constants. By removing these constants, all of the internal Enterprise Library instrumentation will be disabled.
- Recompile.
Of course, with this solution, we introduce additional configuration management overheads. Which application works with instrumentation? Which one don't? In addition, 2 versions of EL assemblies must be maintained; with instrumentation, and without.
Headache...
Sunday, August 07, 2005
Multithreading with System.Collections.Hashtable
The Hashtable collection in .NET framework is used for storing key-values pairs as a collection. It also supports the IEnumerable interface so that we can use C#'s convenient 'foreach' to iterate through its elements. Under the hood, the 'foreach' uses the IEnumerator.MoveNext() to iterate through the collection.
In using a Hashtable within a multi-threaded scenario. MSDN documentation states the following for thread safety:
"Thread Safety
To support one or more writers, all operations on the Hashtable must be done through the wrapper returned by the Synchronised method.
Enumerating through a collection is intrinsically not a thread-safe procedure. Even when a collection is synchronized, other threads could still modify the collection, which causes the enumerator to throw an exception. To guarantee thread safety during enumeration, you can either lock the collection during the entire enumeration or catch the exceptions resulting from changes made by other threads."
Now what this really means is this; The Hashtable supports multiple concurrent read operations, however, if the collection is modified during these iterations i.e. Hashtable.Add() or Hashtable.Remove(), then an InvalidOperationException will be generated.
For example:
public class TestMultithreadingHashtable{
private Hashtable table;
public void Main()
{
Hashtable table = new Hashtable();
//code to insert a lot of elements.
Thread readThread = new Thread(new ThreadStart(ReadFromHashtable));
Thread writeThread = new Thread(new ThreadStart(WriteToHashtable));
readThread.Start();
Thread.CurrentThread.Sleep(500);
writeThread.Start();
}
{
table.Add(key, element);
//this will invalidate any existing IEnumerator.
// no exception when this is executed on write thread.
}
public void ReadFromHashtable()
{
IEnumerator enumerator = table.GetEnumerator();
//use this to iterate through elements.
while (enumerator.MoveNext())
//InvalidOperationException is thrown immediately after
//write thread has executed Add() as IEnumerator is no longer valid.
{
//code to display elements.
}
}
Upon a more thorough digging about in MSDN on IEumerator, the following details clarifies things a little.
"An enumerator remains valid as long as the collection remains unchanged. If changes are made to the collection, such as adding, modifying or deleting elements, the enumerator is irrecoverably invalidated and the next call to MoveNext or Reset throws an InvalidOperationException. If the collection is modified between MoveNext and Current, Current will return the element that it is set to, even if the enumerator is already invalidated.
The enumerator does not have exclusive access to the collection; therefore, enumerating through a collection is intrinsically not a thread-safe procedure. Even when a collection is synchronized, other threads could still modify the collection, which causes the enumerator to throw an exception... "
So to sum it up, multiple concurrent read operations on a Hashtable is fine. If there is an operation that modifies the content of the table, it must be synchronised against the read operations.
