Etiqueta: ddd

Recursos sobre Persistencia Objeto-Relacional

Persistir Objetos en una base de datos relacional es una problemática muy común sobre todo en el desarrollo de las denominadas «aplicaciones enterprise». Los desafíos de esta cuestión han sido caracterizados con nombre propio: «Impedance Mismatch«. Hoy en día esta problemática ha sido resuelta por diversas en herramientas entre las que a mi entender se destacan Hibernate(Java) y ActiveRecord(Ruby).

En MeMo2 trabajamos con Ruby pero evitamos el uso de ActiveRecord de la manera tradicional pues resulta intrusiva en el modelo de objetos, ya que obliga a que las clases a persistir deban heredar de una clase de ActiveRecord. La intención en MeMo2 es implementar lo que desde una perspectiva Domain-Driven Design suele denominarse «Persistence Ignorance», esto es que el modelo de objetos permanezca «ignorante» de la tecnología de persistencia. Si bien es importante que los alumnos entiendan los desafíos de esta problemática, no esperamos que implementen un ORM pero si que respeten la idea de «Persistence Ignorance». Es por ello que a lo largo de varios cuatrimestres hemos provisto a los alumnos con ejemplos de implementación de persistencia basados en la idea de Repositorios y utilizando distintos frameworks. Basados en el feedback que los propios alumnos nos han dado, este cuatrimestre agregamos un ejemplo de implementación basado en Sequel y una serie de video que explican la problemática y algunas técnicas de diseño.

El primer video explica conceptual el problema de guardar objetos en una base de datos relacional.

El segundo video explica desde los distintos modelos con los lidiamos en el desarrollo de una aplicación y como es la relación entre ellos a la hora de implementar la persistencia.

Finalmente, el tercer video menciona una seria de recomendaciones para implementar la persistencia de forma trasparente utilizando el patrón Repositorio.

Object creation review

When working with OO languages we use constructors to instantiate our objects. Constructors should always return a valid instance ready to use, you don’t need to perform any additional task before using the instance. In some occasions an object need some collaborators to perform its work and in that cases you will need to provide a constructor that takes this collaborators as parameters.

The syntax of constructors may vary depending on the language, in C++like languages (Java, C# and others) constructors take the same name of the class. In cases like Object Pascal (the language behind Delphi) you use the keyword constructor to declare constructors. And finally  we have Smalltalk-like cases, where you constructors are simply class methods, no special name , no keyword, just call them as you like.

One practice I like when defining constructor is to give them some semantic, this is a very common practice for those who work with Smalltalk but it is not so common for those working with C++ like languages. Many times when I work with C# or Java, I find classes that provide several constructors with different parameters, but is not so clear how this constructors work, of course al of them return a valid instance, but do they perform any additional task? is there any particular property in the create instance? Let’s see an example to illustrate it. Let’s define a person class with first name (mandatory) and last name (optional).

In C# we could have something like this:

public class Person
{
public Person (string firstName) {…}
public Person (string firstName, string lastName) {…}
}

And to use it:

Person aPerson = new Person("John");
Person anotherPerson = new Person("John", "Foo");

In Smalltalk this could be:

Object subclass Person
Person class>>withFirstName: aFirstName.
Person class>>withFirstName: aFirstName andLastName: aLastName.

And we use it this way:
aPerson := Person withFirstName: 'John'.
anotherPerson := Person withFirstName: 'John' andLastName: 'Foo'.

As I said, this practice is very common in Smalltalk, but it can be used with C++like languages, in fact it is recommended by Kent Beck in his book Implementation Patters that is focused on Java. Let’s refactor the C# person class to use this pattern.

public class Person
{
public static Person WithFirstName(string firstName) {...}
public static Person WithFirstNameAndLastName(string firstName, string lastName) {...}
}

( I know, Smalltalk’s ability of merging method name and parameters provides a great user experience that is impossible to emulate with C++ like languages. )

DDD: implementing object’s identity

One important thing to consider when implementing a domain-driven design is object identity.

In most languages, each object identity is determined by the memory address of the object, but if we are implementing a DDD then we shoud redefine object identity in terms of our domain. For example, let’s suppose we are working in a bank domain, and we have an Accout class, then you should define the identity of Account objects based on the account number.

When working with C#, there are four methods related to the identity of objects, all of them defined in the root class Object:

public virtual bool Equals(object obj);

public static bool Equals(object objA, object objB);

public virtual int GetHashCode();

public static bool ReferenceEquals(object objA, object objB);

Let’s analyze them one by one.

bool Equals(object obj)

By default this method will compare object’s memory address, but that is not correct when implementing a DDD. As mentioned before identity of our domain classes should be define in tern of domain concepts, so we should override this method. Continuing with the Account class example, this method should compare account number: same account number then same object.

public override bool Equals(object obj)

{

Account otherAccount = obj as Account;

if (otherAccount == null)

return false;

return this.Number.Equals(otherAccount.Number);

}

static bool Equals(object objA, object objB)

This method is static and just invokes Equals method of instance objA passing to it the objB as a parameter.

int GetHashCode()

This method is not directly related to object’s identity. It is used when a hash code is needed to represent the object, for example if we want to store the object in a hash-based struture like a hashtable. From msdn: » The default implementation of the GetHashCode method does not guarantee unique return values for different objects. Furthermore, the .NET Framework does not guarantee the default implementation of the GetHashCode method, and the value it returns will be the same between different versions of the .NET Framework. Consequently, the default implementation of this method must not be used as a unique object identifier for hashing purposes.»

When implementing a DDD we should override this method in our domain classes to return different values for not equal objects. In the Account class example we could use the account number as the hash code.

public override int  GetHashCode()

{

return this.Number;

}

static bool ReferenceEquals(object objA, object objB)

This method simply compares memory addresses, the same behaivour that Equals default implementation.

Well, this is it, I hope this post to clear enough.

If you want to see some tests running to validate this and make your own test you can download my code from here.

In future posts I will write about the relation of this with the equals operator (==) and the importance of equals method when working with persistence frameworks like NHibernate.