Storing a collection of reference types and value types is a common practice in Software Development. Since the introduction of the Generic Types in Framework 2.0 working with collection elements has become much easier.
The ArrayList type used to be the common type for storing objects but the new kid on the block “Generic List” has taken away the popularity from the ArrayList. Since elements were stored as an object casting reference types from object to enclosing type needed the extra coding and decreased the performance. With value types the developers faced the boxing issue at storing time and unboxing when the data was retrieved from an instance of ArrayList object.
With Generic List type you have instance access to the elements of an instance generic List object without the need to cast or unboxing the data. The generic List has far more members that its predecessor ArrayList. I’m not going to delve into each member and explain what they do. I’m sure most of you already familiar with them and they have been well documented on MSDN Library or by other developers.
In short the generic List functionality (members) is best used with .Net Framework’s value types but not with reference types. As long as you are using generic List to pass a collection of data around you would never face the fundamental problem I’m about to highlight in here.
Please examine the following snippet:
List<string> names = List<string>();
if (names.Contains("Mark"))
{
// Do Something
}
The above code makes generic List a glorious type to work with because it offers the encapsulated “Contains” logic to see if values exist in the collection or not at ease.
Please examine the following snippet:
List<Person> persons = new List<Person>();
if (persons.Exists(this.MarkExists))
{
//Do Something
}
private bool MarkExists(Person person)
{
return (person.FirstName == "Mark");
}
On paper the capability of generic Predicate delegate combined with other generic types such as generic List is smashing but at least in case of generic List it offers hardly any practical solutions in real world.
The downside of working with generic Predicate and generic List are as follow;
- Possibility of duplicating logics: Even if you declared MarkExists method with public or internal visibility access you can’t be assured other types can access the enclosing type at all time.
- Too many members to declare: You can’t possibly declare one target method for every name there is in Person’s FirstName property. How about other business logics that you might have with other members in Person type?
In one of my earlier blog posts I talked about encapsulating logics which is one of the most fundamental practices in SD. Any logics that you would write against a generic list object would not be necessarily encapsulated. This is the very reason why as soon as I need to write any logic against a generic List object instead I would declare a new type and extend the generic Collection type and encapsulate them within the extended generic Collection type.
I can pass on such objects from members to members or from the declaring type to another types knowing I have access to all predefined logics against my custom collection type.
The generic Collection type has very simple object model and extremely easy to extend. This is actually an advantage that the generic Collection has a very simple object model. The generic Collection type can be found in System.Collections.ObjectModel namespace.
If you only develop database applications then the chances that you are using more complex collection types are high such as the powerful collection types that you would get with the O/RM tools or the custom collections you built for your own needs. This post is less relative to entities and entity collections.
Smarties 2008 is not a database application but for almost every type there is you would find an extended generic Collection.
Often you are required to introduce sorting capability to the extended Collection types or add a simple AddRange() method to ease up inserting objects to the collection. The generic Collection does not offer AddRange() method by default but from the constructor you can pass any objects that implement the generic IList interface. We all know that not always it is possible to pass data on initialisation time.
I’d get a lot of joy out of my work when the output is of something that is both practical and so damn easy to use. You would find many commands in Smarties 2008 that are unique and in terms of productivity they are simply unbeatable. The same day that I published this post I released version 1.9.0 of Smarties 2008 that the main focus was to introduce sorting to the extended Collection type and to ease up working with generic IComparer, IComparable, and generic IComparable interfaces.
I have created a demo for each supported language (C# and VB.NET) that is not just specific to a single command (as I often do). It shows off several commands in actions and you will see how easy it is to create sortable collections using Smarties 2008. Please don’t think entity collections or try to compare what you see in the demo with what you get with entity generator of O/RM tools. In real world you would have far more non-entity types than entity types anyway.
Before watching the demo I would like you to think of a class with at least three properties, an extended generic Collection type since you would be encapsulating logics, and the comparer type that is needed for sorting the reference types in the collection. Lots of work for very basic functionality even if you would use the copying and pasting techniques, isn’t it?
To be precise the demo takes 51 seconds to produce the output. In fact the only thing was done for this demo was the three private fields that I declared by hand earlier and the rest was done just by few clicking of the mouse.
Here is the link to Demo Page.