Signum Framework Logo
"Open framework that encourages convention over configuration, using C# code,
not XML files, to model at the right level of abstraction and achieve deadlines.
...but also has a full Linq provider, and syncs the schema for you!"



Source code




Modified on 2009/03/18 03:42 by helen Paths: Documentation Categorized as SignumUtilities


Signum.Utilities is the very basic Assembly of Signum Framework. It's referenced by any other assembly in the framework and it can be used independently.

Signum.Utilities is just a set of general purpose tools, following the design lines below:

  • Small over Big: Fill small gaps in the .Net Framework, we don't want big features in Signum.Utilities.
  • Functional over Imperative: Once you get used, functional style is more readable, scalable and shorter. Lambda expressions are here to stay.
  • Handy over Intellectually gratifying: No Y conbinator here.
  • No dependencies: Without dependent assemblies it can easily be added to any project.

Also, where Signum.Utilities really shines is when writing loading programs for your legacy data: Yeah, Signum Framework forces you to change your Database and this is not something Frameworks usually do, but it does so for a good reason and we help you in the process giving you powerful tools to manipulate your legacy data making it fit in your freshly designed entity model, normalizing it in the process.

About the Documentation

This library is different to the other ones. Here we have tiny methods, usually 2 or 3 lines long, that are easy to understand.

The signature of the method is usually enough and, if there's any doubt, just look at the source code (Signum Framework is Open Source!).

The main task of Signum.Utilities documentation is to improve discoverability of the library.

Signum.Utilities Motivation (Advanced Topic)

.Net Framework is a huge framework containing lots of functionality. Really, it is so complete that is hard to find functionality not considered already in the framework.

Some API, however, are not as convenient to use as they could be. They where designed for .Net 1.1 and, with the arrival of Linq, the way we code has (or should have) changed so much that this API look a bit aged now:

  • Generics: Until .Net 2.0 there was no Generic support, and even in .Net 2.0 they were kind of 'embarrassed' of using generics. It looked like an isolated experiment in System.Collection.Generics.

Example: Enum class lacks some generic facilities.

  • Delegates: Even having delegates from day 1, the lack of a convenient syntax to express anonymous delegates (or lambda expressions), and the inertia of Jave design patterns, produced a missuse of delegates.

Example: IComparer or IComparer<T> are interfaces with just one method, they should be delegates instead.

  • Extension Methods: This feature allows improvement of client code readability and discoverability while preserving good architecture in your library (assembly dependencies, for example) by making static external methods look like instance methods. This feature, however, was added too late in the framework (.Net 3.5) so almost no class (but Linq) uses it jet.

Example: Converter.ChangeType could be an extension method over any IConvertible instead.

  • Concurrency and Immutability: With the appearance of Linq and the disappearance of the free lunch, a more functional way of programming is encouraged in order to archive parallelism. Almost everything in the .Net framework but ReadOnlyCollection is mutable at this moment :S.

This problem, however, it's going to be addressed by the inclusion of Parallel Extensions in .Net 4.0. So we are not planning any tool for that.
Creative Commons License Signum Framework Site by Signum Software is licensed under a Creative Commons Attribution 3.0 License.
Powered by ScrewTurn Wiki version