WELCOME

February 10th, 2008

 

This website is about XOODBS assembly to program software for Microsoft and Mono .NET platform.

 

 

First release delayed

October 23rd, 2009

Roadmap

Due to some improvements, the first release of the Core Model is delayed to 2010.

Print Print      Email Email

 

Are interfaces evil or misused ?

July 25th, 2009

C# and .NET

There are several considerations and practices concerning interfaces

Some developers say that interfaces can be used as a replacement of multiple inheritance mechanisms, which cause complexity and ambiguity. But each feature must be implemented each time it is declared: this is not an inheritance, this is a wrapper to the description of a part of a group of classes, like IDisposable. It is the same as a multiple inheritance with one implemented class and some abstract classes: it is a particular case which allows only one way hierarchy with interfaces as abstract connectors that describes services.

Some developers say that interfaces can be used to separate the access to an object of this instance. Historically, interfaces are a COM & DCOM heritage: they are used to manipulate components services, whatever objects are, where they are, and how they are implemented. Interfaces are not a replacement to multiple inheritance, they are something else.

Recommended articles:
A plea for full multiple inheritance support in .NET
A Typed Intermediate Language for Compiling Multiple Inheritance

Read more…

Print Print      Email Email

 

Design flaws of the singleton pattern in C#

July 21st, 2009

C# and .NET

The paradigm

Consider this common singleton pattern implementation:

public class Singleton
{
  static private readonly object locker = new object();

  static public Singleton Instance
  {
    get
    {
      lock ( locker )
      {
        if ( _Instance == null ) _Instance = new Singleton();
        return _Instance;
      }
    }
  }
  static private volatile Singleton _Instance;

  private Singleton() { }
}

The problem is that you can inherit this class and create a public constructor if there is no private constructor. Furthermore, static members are allowed. This is no longer a singleton at all. Setting the class as sealed can be an acceptable solution, but you must implement singleton by singleton, i.e., more than ten lines. Thus, coding a such singleton can be the source of many errors and difficulties. Thinking with factoring is not only an agile principle, it is a mathematical theorem.

Defining a generic singleton

A generic solution is to check the absence of static members and that there is only one parameterless private constructor, or an exception is thrown. Singletons that inherit this class can’t be inherited and must be sealed. Moreover, the implementation of singleton types are checked at program startup. Therefore, it is not the best solution, but the only thing to do is to create one parameterless private constructor, no static members, and seal the class.

  Generic Persistent Singleton Sample (52.9 KiB)

Read more…

Print Print      Email Email

 

Development status

July 13th, 2009

Roadmap

It was decided to merge the code into one single library whose the name is officially XOODBS that provides a Core Model (old XAM library) and an Entity Model (old XOODBS library).

Time spent on the project is approximately one to two hours per day. The first release is expected by the end of this year.

The progress is estimated at 80% without the Entity Model package :

  • Application : 100%
  • Diagnostics : 80%
  • FileSystem : 80%
  • Network.Remoting : 100%
  • Threading : 100%
  • ObjectModel : 50%
  • ObjectModel.Container : 80%
  • ObjectModel.EntityModel : 20%
  • Testing : 90%
  • Testing.UnitTest : 50%

Print Print      Email Email

 

Persistence guidelines

July 13th, 2009

Entity Model

The XOODBS goal is to provide a simple and powerful Persistence Framework that allows programmers :

  • To define classes structure,
  • To implement operations,
  • To create, modify and delete instances,
  • As they use the standard features of a .NET object language,
  • And nothing else but select the type of a container and its location, as well as locking items.

Through a caching system, an ObjectEntityMapper handles in a transparent manner the presence of data items in the memories of the SessionManager and in the storage namespaces provided by the ObjectContainer.

In this way, instances of items stored in the database are conventionally used as if there is an unlimited and persistent 64 bits memory, according to the limits and performances provided by container, operating system, hardware and network connection.

The last limit is that an object, or a set of objects working together, whose size is not loadable in the physical and virtual memory of the system is not usable, unless they manage their own aggregated buffers, ie it is better to store data such as large multimedia items in separate files on disk.

You can see the Example Preview for more details.

// Remark : only value modifications can be cancelled or applied, not insert or delete
SessionManager session = new SessionManager < SQLiteContainer > ("db.bin", "user", "pwd");
session.AutoLockEdit = true;
var list = session.Alarms.FindInactive();
foreach (var item in list)
{
    session.Alarms.Remove(item);
    session.Recycle.Add(item);
}
session.Close();

Print Print      Email Email