The road to Salamanca

To content | To menu | To search

Wednesday, January 28 2009

First maintenance release : 0.9.1

We discovered an issue in the current release of the Salamanca libraries (0.9.0) that was important enough to make us deliver a maintenance release : version 0.9.1. You can use these new libraries as a drop in replacement for the old ones.

Note that the issue discovered concerns only the libraries that depend on Enterprise Library :

We previously compiled these libraries against version 4.1 of Enterprise Library, which requires the .NET Framework 3.5. As our libraries were only supposed to target the .NET Framework 3.0 at best, this introduced a very unwelcome dependency. So the new version is compiled against version 3.1 of Enterprise Library, which only requires the .NET Framework 2.0.

As for the next release (1.0.0), these dependencies has been fixed as followed :

  • .NET Framework 2.0, 3.0 targeted libraries : depend on Enterprise Library 3.1.
  • .NET Framework 3.5 targeted libraries : depend on Enterprise Library 4.1.

Did I just write about version 1.0.0 ? Here is in two sentences what is to be expected :

  • updated libraries, now targeting the .NET Framework 3.5 as well.
  • our first SDML designer ! Still limited, but entirely functional, with code generation from SQL to C# entities…

image

Stay tuned !

Thursday, October 9 2008

QuickStart : the Activity

Whereas Data Access could be considered as yet another solution to a very common problem (the ORM problem), Data Activities is quite original in its conception and implementation. The concepts involved here are much less refined or complex, but have already proved to be very powerful.

FindProductListByNameFirst of all, we have to define an activity in terms of questions and treatments. The simplest activity I could imagine is the following :

  • this activity is about getting a list of products that match a specified name.
  • the first state is a question that asks for the name.
  • the second (and last) state is a treatment that finds the corresponding states.
  • let's add to this a rule that specifies that the name we are looking for should not be empty (nor null).

For this activity, we'll reuse the Product class we have defined in the Domain Model quick start. The proper way to implement this would be to add a FindByName method to this class and query the database, but we'll do it the Activity way this time.

An activity manipulates data. We need a class to store :

  • the name of the Product.
  • the list of products matching that name.

There is a base class in the Salamanca.DataActivities that will help us implement the IActivityData interface :

using System;
using System.Collections.Generic;
using System.Collections.ObjectModel;
using Salamanca.DataActivities;

namespace QuickStart
{
public class Data:
ActivityData
{
private struct Backup
{
public string Name;
public Product[] Products;
}

protected override object CreateBackup()
{
Backup ret=new Backup();
ret.Name=_Name;
ret.Products=_Products.ToArray();
return ret;
}

protected override void RestoreBackup(object backup)
{
Backup b=(Backup)backup;
_Name=b.Name;
_Products=new List<Product>(b.Products);
}

public string Name
{
get { return _Name; }
set { _Name=value; }
}

public IList<Product> Products
{
get { return _Products; }
set { _Products=new List<Product>(value); }
}

private string _Name;
private List<Product> _Products=new List<Product>();
}

}

You see there is a bit more than just having a Name and a Products property. When inheriting from ActivityData, you have to implement two abstract methods that create and restore backups on the data. We won't really need this system in this activity, but data must implement IBackupable and this is quite straightforward as you can see in the code above.

Our activity will ask a question. This question is going to be implemented in the UI layer (likely via a TextBox on Windows Forms), so we need a way to allow it to plug itself into our activity. We do that via a question factory, as follows :

using System;
using Salamanca.DataActivities;
using Salamanca.DataActivities.UI;

namespace QuickStart
{
public abstract class QuestionFactory
{
public abstract Question AskProductName(IActivityController controller);
}
}

Our question state will need this QuestionFactory (or, rather, an implementation of it). And I anticipate that our treatment state will need a DataMapperCollection as we will retrieve all the products from the database via the Product.FindAll method. These are the dependencies of our activities, and we will group them in a parameter class :

using System;
using Salamanca.DataAccess.Collections;
using Salamanca.DataActivities;

namespace QuickStart
{
public class Parameters:
IQuestionFactoryParameters<QuestionFactory>
{
public Parameters(QuestionFactory factory, DataMapperCollection dataMappers)
{
_QuestionFactory=factory;
_DataMappers=dataMappers;
}

public DataMapperCollection DataMappers
{
get
{
return _DataMappers;
}
}

public QuestionFactory QuestionFactory
{
get
{
return _QuestionFactory;
}
}

private DataMapperCollection _DataMappers;
private QuestionFactory _QuestionFactory;
}
}

We are now ready to create our two states. The first one must implement IActivityInitialState, which is just a marker interface. As a question state, we can simply derive it from the QuestionActivityState base class. The second state just fills our Data with a list of products matching the name that was returned by the question :

using System;
using System.Collections.Generic;
using Salamanca.DataActivities;
using Salamanca.DataActivities.UI;
using Salamanca.DataRules;

namespace QuickStart
{
public class FindProductListByName:
QuestionActivityState<Data>,
IActivityInitialState
{
public FindProductListByName(Data data, QuestionFactory factory, DataMapperCollection dataMappers):
base(data, new Parameters(factory, dataMappers))
{
}

protected override IList<IRule> CreateRules()
{
IList<IRule> ret=base.CreateRules();
ret.Add(
new PredicateRule<FindProductListByName>(
"The name must not be empty.",
new Predicate<FindProductListByName>(
delegate(FindProductListByName s) {
return !string.IsNullOrEmpty(s.Data.Name);
}
)
)
);

return ret;
}

protected override void OnInitialized(ActivityStateEventArgs e)
{
Question=((Parameters)Parameters).QuestionFactory.AskProductName(e.Controller);
base.OnInitialized(e);
}

protected override IActivityState NextState
{
get { return new FindProductListByNameFindProducts(Data, (Parameters)Parameters); }
}
}

internal class FindProductListByNameFindProducts:
ActivityState<Data>
{
public FindProductListByNameFindProducts(Data data, Parameters parameters) :
base(data, parameters)
{
}

protected override ActivityStateResult Handle(IActivityController controller)
{
List<Product> allProducts=new List<Product>(Product.FindAll(((Parameters)Parameters).DataMappers));
Data.Products=allProducts.FindAll(
new Predicate<Product>(
delegate(Product p) {
return p.Name.Contains(Data.Name);
}
)
);

return ActivityStateResult.Next;
}

protected override IActivityState NextState
{
get { return new EndActivityState<Data>(Data); }
}
}
}

Note in the question state how we enforced our business rule (the name must not be empty).

Our activity is ready. Or is it ? What we have here is still an abstraction, and we need an implementation for our QuestionFactory. And that is precisely the magic of it all : we just need a concrete QuestionFactory.

Say, for instance, that we want to test our activity : we need a question factory that automatically provides the Data with test product names and checks the results. Here is an implementation of this question factory :

internal sealed class TestQuestionFactory:
QuestionFactory
{
public TestQuestionFactory(string name)
{
_Name=name;
}

public override Question AskProductName(IActivityController controller)
{
Question ret=new AnsweredQuestion();
ret.Answering+=new EventHandler<AnswerEventArgs>(
delegate(object sender, AnswerEventArgs e) {
((Data)e.Data).Name=_Name;
}
);

return ret;
}

private string _Name;
}

Based on this factory, a test would look like this (there are two products containing Queso in their name in the Northwind database) :

[TestMethod]
public void CanFindProductList()
{
Data data=new Data();
ActivityController controller=new ActivityController(
new FindProductListByName(
data,
new TestQuestionFactory("Queso"),
DataMappers
)
);
controller.Execute();

Assert.IsTrue(controller.HasCompleted);
Assert.AreEqual(2, data.Products.Count);
}

You can see here how an ActivityController is used to execute an activity. As all answers are automatically provided, our activity is executed from the beginning to the end in one phase. In a Windows Forms application, the execution would stop at the question state to let the user fill a text box in. When a Find button would be clicked, the controller would be told to resume the activity execution.

You can find a complete working example, as a Visual Studio 2008 solution, here. The same activity is implemented as a unit test, and as a Windows Forms application (the underlying database is Northwind on SQL Server, for which a data file is included in the downloadable sample).

Tuesday, September 23 2008

QuickStart : the Domain Model

Now that the first release is out, let's start playing with it. The first step is to design our business objects ; we'll eventually have a DSL for this (the SDML), but basic UML will do for now.

Quick Start (UML)We'll begin with a (very) simple model. Sorry, I could not think of anything more simple ;-) Our application will deal with products, whose sole property is their name.

The associated database could be created with the following script :

CREATE TABLE Products (
ProductID INT IDENTITY(1, 1) NOT NULL,
ProductName VARCHAR(40) NOT NULL
CONSTRAINT PRIMARY KEY (ProductID)
);

Now we can create our Data Access Layer. What we need first is a class to handle the primary key for our product. We have a base class for it, in the Salamanca.DataAccess namespace :

using System;
using Salamanca.DataAccess;

namespace QuickStart
{
public class ProductPrimaryKey:
PrimaryKey<int>
{
public ProductPrimaryKey():
base()
{
}

public ProductPrimaryKey(int key):
base(key)
{
}

public static implicit operator ProductPrimaryKey(int key)
{
return new ProductPrimaryKey(key);
}

public static explicit operator int(ProductPrimaryKey key)
{
return key.Value;
}
}
}

Then we need a class to be used as a data holder. More specifically, it will be used as a Data Transfer Object :

using System;
using Salamanca.DataAccess;

namespace QuickStart
{
public class ProductDataTransfer:
IDataTransferObject
{
public object Clone()
{
return MemberwiseClone();
}

public int Id;
public string Name;
}
}

What remains to be defined is our Domain Model and our Data Mapper. To avoid too tight coupling between both, we'll define an interface that will have to be implemented by a product related Data Mapper :

using System;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;

namespace QuickStart
{
public interface IPersonMapper:
IDataMapper
{
Product Find(ProductPrimaryKey key, DataMapperCollection dataMappers);
DomainModelKeyedCollection<Product> FindAll(DataMapperCollection dataMappers);
}
}

For a starter, we'll only need two methods :

  • one to get a specific product instance from the data backend.
  • one to get all the products form the data backend. The DomainModelKeyedCollection returned can be used a regular Collection, as well as a Dictionary where products are indexed with their primary keys.

Now we're ready to define our Domain Model :

using System;
using System.Collections.Generic;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;
using Salamanca.DataRules;


namespace QuickStart
{
public class Product:
DomainModel<ProductPrimaryKey, ProductDataTransfer>
{

public Product():
base()
{
}

public Product(DataMapperCollection dataMappers):
base(dataMappers)
{
}

protected override ProductPrimaryKey CreateId()
{
return new ProductPrimaryKey(Data.Id);
}

public static Product Find(ProductPrimaryKey key, DataMapperCollection dataMappers)
{
return ((IProductMapper)dataMappers[typeof(Product)]).Find(key, dataMappers);
}

public static IList<Product> FindAll(DataMapperCollection dataMappers)
{
return ((IProductMapper)dataMappers[typeof(Product)]).FindAll(dataMappers);
}

internal void SetId(int id)
{
Data.Id=id;
}

[StringLengthRule(40)]
[NotNullRule]
public string Name
{
get
{
Load(true);
return Data.Name;
}
set
{
if (Data.Name!=value)
{
Data.Name=value;
RaisePropertyChanged("Name");
}
}
}
}
}

As you can see, this is quite straightforward : just inherit from Salamanca.DataAccess.DomainModel, override CreateId and add your properties. The static methods have just been defined here for convenience. Also, note the attributes above the Name property, that define our first business rules.

Final step : define a Data Mapper for our product. We'll choose the ADO .NET based abstract implementation that is found in the Salamanca.DataAccess.Data namespace as a base :

using System;
using System.Collections.Generic;
using System.Data;
using System.Data.Common;
using Salamanca.DataAccess;
using Salamanca.DataAccess.Collections;
using Salamanca.DataAccess.Data;

namespace QuickStart
{
public partial class ProductMapper:
DataMapper<Product , ProductDataTransfer ProductPrimaryKey>,
IProductMapper
{
public ProductMapper(DbConnection connection, ICacheManager cacheManager):
base(connection, DomainModelCreator.CreateDefault<Product>(), cacheManager)
{
}

public DomainModelKeyedCollection<Product> FindAll(DataMapperCollection dataMappers)
{
IDbCommand[] commands=new IDbCommand[1];

commands[0]=Connection.CreateCommand();
commands[0].CommandType=CommandType.Text;
commands[0].CommandText="SELECT ProductID, ProductName FROM Products";

return Load(commands, dataMappers);
}

protected override IList<IDbCommand> CreateSelectCommands(ProductPrimaryKey key)
{
IDbCommand[] commands=new IDbCommand[1];

commands[0]=Connection.CreateCommand();
commands[0].CommandType=CommandType.Text;
commands[0].CommandText="SELECT ProductName FROM Products WHERE ProductID=@Id";

IDbDataParameter p=commands[0].CreateParameter();
p.ParameterName="@Id";
p.DbType=DbType.Int32;
p.Value=key.Value;
p.Direction=ParameterDirection.Input;
commands[0].Parameters.Add(p);

return commands;
}

protected override IList<IDbCommand> CreateDeleteCommands(ProductDataTransfer data)
{
IDbCommand[] commands=new IDbCommand[1];

commands[0]=Connection.CreateCommand();
commands[0].CommandType=CommandType.Text;
commands[0].CommandText="DELETE FROM Products WHERE ProductID=@Id";

IDbDataParameter p=commands[0].CreateParameter();
p.ParameterName="@Id";
p.DbType=DbType.Int32;
p.Value=data.Id;
p.Direction=ParameterDirection.Input;
commands[0].Parameters.Add(p);

return commands;
}

protected override IList<IDbCommand> CreateInsertCommands(ProductDataTransfer data)
{
IDbCommand[] commands=new IDbCommand[1];

commands[0]=Connection.CreateCommand();
commands[0].CommandType=CommandType.Text;
commands[0].CommandText="INSERT INTO Products (ProductName) VALUES(@ProductName)";

IDbDataParameter p=commands[0].CreateParameter();
p.ParameterName="@Name";
p.DbType=DbType.String;
p.Value=data.Name;
p.Direction=ParameterDirection.Input;
commands[0].Parameters.Add(p);

return commands;
}

protected override IList<IDbCommand> CreateUpdateCommands(ProductDataTransfer data)
{
IDbCommand[] commands=new IDbCommand[1];

commands[0]=Connection.CreateCommand();
commands[0].CommandType=CommandType.Text;
commands[0].CommandText="UPDATE Products SET ProductName=@Name WHERE ProductID=@Id";

IDbDataParameter p=commands[0].CreateParameter();
p.ParameterName="@Name";
p.DbType=DbType.String;
p.Value=data.Name;
p.Direction=ParameterDirection.Input;
commands[0].Parameters.Add(p);

p=commands[0].CreateParameter();
p.ParameterName="@Id";
p.DbType=DbType.Int32;
p.Value=data.Id;
p.Direction=ParameterDirection.Input;
commands[0].Parameters.Add(p);

return commands;
}

protected override ProductDataTransfer GetDataTransferObject(IList<IDataRecord> records)
{
ProductDataTransfer data=new ProductDataTransfer();

int ord=records[0].GetOrdinal("ProductID");
if (!records[0].IsDBNull(ord))
data.Id=records[0].GetInt32(ord);

ord=records[0].GetOrdinal("ProductName");
if (!records[0].IsDBNull(ord))
data.Name=records[0].GetString(ord);

return data;
}

protected override void OnInserted(Product domainModel, IList<IDbCommand> commands)
{
IDbCommand command=Connection.CreateCommand();
command.CommandType=CommandType.Text;
command.CommandText="SELECT @@IDENTITY";
command.Transaction=commands[0].Transaction;

domainModel.SetId(Convert.ToInt32(command.ExecuteScalar()));

base.OnInserted(domainModel, commands);
}
}
}

That's it : derive from DataMapper and fill the gaps with pure ADO .NET code. You can already understand that this is where code generation will greatly improve the developer productivity.

Our Data Access Layer is now complete : we can build a simple application based on it. The only (?) tricky thing is that you will need to create an instance of DataMapperCollection. For our sample, simply use this code :

DataMapperCollection _DataMappers=new DataMapperCollection();
_DataMappers.Add(typeof(Product), new ProductMapper(Connection, new NoCacheManager()));

It creates a new collection based on a prexisting Connection, and our data is simply not cached in memory.

You can find a complete working example, as a Visual Studio 2008 solution, here. As you can see, we can build a simple application that integrates our Domain Model in a very few lines of code, with business rules validation (the underlying database is Northwind on SQL Server, for which a data file is included in the downloadable sample).

Quick Start Sample

Next time, we will create our first activity. Stay tuned !

Monday, September 8 2008

Inside the libraries (III) : Data Activities

Data Activities defines the base classes that help us implement our architectural pattern, centered around business activities. All the concepts developed in this context owe a lot to the vision and the ideas of Yves Darmaillac.

We define an activity as a part of a business process. All the business process parts that are involved in a business application define this application activities. An activity is a , comprising two kinds of states :

  • treatment states : those require no external data (think user interaction). For instance, a treatment state can perform an action on our domain model (create a new reservation), or directly on the data (calculate booking fees). All a treatment state needs to perform its action is data.
  • question states : those do require external data. For instance, a question state can ask for data for a domain model instance (fill reservation details), or it can ask for a specific domain model instance (pick up your seat). Usually, a question is answered via user interaction (but not necessarily, like in the case of unit tests where answers can be automated).

The golden rule here is to make sure that all the application behavior is defined in terms of activities. Treatments are by definition self-sufficient and generic. Questions define abstractions that have to be implemented by the HMI layer. In effect, such abstractions can be implemented by all kinds of presentation technologies (console applications, Windows Forms, ASP .NET, WPF...) with no impact on the business logic.

BasicsThe fundamental interfaces defined in this library are :

  • IActivityState is an interface implemented by an activity state, and treatment states in particular. IQuestionActivityState is a specialization that is implemented by a question state.
  • IActivityData is implemented by an activity data holder type : it holds the data that is manipulated by a specific activity.
  • IActivityParameters is implemented by an activity parameters holder type. An activity parameter could be seen as an immutable activity data.
  • IActivityController is implemented by an activity controller. Such a class is essential to the activity execution : it initiates the activity, terminates it and controls all the state transitions in between.

All the states must be validated before transition : this is achieved via the integration of Data Rules. The library defines base implementations for all these interfaces, and helpful classes to implement questions in specific presentation technologies (so far Windows Forms and ASP .NET).

Activities are at the core of our architecture : they manipulate data and act as a separation of concerns between the business logic and the presentation. In the future, we will be able to design our activities via our own DSL (SAML), and have base implementations (and best practices) for questions in other technologies such as WPF or ASP .NET AJAX.

I would like to finish with an analogy that might confuse some readers, but hopefully enlighten others : imageI like to think of a business activity as a RNA translation process, which is part of the protein biosynthesis. The elements involved in this process are :

  • a mRNA template. It holds the code for a specific protein. This code has a start and an end, and has to be followed in order. This is our finite state machine, each codon being seen as a state.
  • a ribosome. This is the protein "factory". It "reads" the codons one by one and performs an action on each of them : add the corresponding amino acid to the chain that will become our protein. This is our activity controller.
  • the protein. This is the result of the entire process. This could be seen as our data.

Monday, September 1 2008

Inside the libraries (II) : Data Access

This one is simple : Data Access is an (ORM) library. As such, it owes a lot to the experience of NourY Solutions in the field of data management. But our ability to structure this experience and put it into words has been greatly enhanced by the remarkable work of Martin Fowler. Many concepts in use in this library are described in his book Patterns of Enterprise Application Architecture.

There are many .NET ORM libraries out there. As evoked before, we don't believe "one size fits all" applies when it comes to ORM ; the mismatch between the object world and the relational one is so huge that it can only be solved by specific solutions under specific sets of constraints. Data Access has been designed with these constraints in mind :

  • integration with Data Rules.
  • easy serialization of business object instances (XML for use in Web Services, for Ajax applications...).
  • persistence backend abstraction : business objects should easily be persisted against any database backend, like a standard RDBMS solution (Sql Server, Oracle, SQLite...), or a web service, or even a flat file.
  • the developer always has to be in control : for instance, no on-the-fly SQL generation (though this could be added later as an option).
  • easy code generation (we want to build a Software Factory, after all !).

This library is organized around 4 interfaces :Basics

  • IDomainModel : is implemented by a . There is also an abstract class (DomainModel) that can be used as a base implementation for your business objects. It provides Data Rules implementation, serialization, and UI integration (through the implementation of the standard IDataErrorInfo, IEditableObject and INotifyPropertyChanged interfaces).
  • IDataMapper : is implemented by a Data Mapper, which basically provides the persistence backend abstraction. The library provides base implementation for persistence based on standard ADO .NET, Enterprise Library Data Access Application Block or Web Services.
  • IDataTransferObject : this interface is implemented by a Data Transfer Object. It is used to hold the data of a Domain Model, to transfer it between a Domain Model and a Data Mapper and to serialize our Domain Models.
  • IPrimaryKey : is implemented by custom Identity Fields types.

A DSL to design our Domain Models would look a lot like a class diagram. And it does actually ;-) (more on that later).

Our plans in the future for this library are :

  • Unity integration.
  • Ability to serialize trees of objects.
  • JSON serialization.
  • Powershell integration.
  • SSIS integration.

Next time will be the time to introduce Data Activities.

Tuesday, August 26 2008

Inside the libraries (I) : Data Rules

Now is the time to delve a bit more into the libraries that lie at the core of our factory. On top of them lie Data Rules.

First of all, note that this library owes a lot to the work of Paul Stovell, and that most of the concepts discussed here can be found in this article of his.

So Data Rules is a validation framework. The goal here is to handle invalid data in your custom types a bit like DataSet does : instead of throwing an exception every time invalid data is affected to it, it records whether the data it is containing is valid or not; and if not, why. This allows for much smoother UI integration (that is what ErrorProvider and IDataErrorInfo are all about).

This library is organized around 2 interfaces :Basics

  • IValidatable is here to help the developer define a custom type that has such a behavior. A validatable type is one for which any instance can be validated against a specified set of rules. In Data Access, our business objects are validatable : you can always know whether data is valid or not, and why. And if you try to persist an invalid business object, you will get an exception.
  • IRule is an interface implemented by a validation rule. A rule can be specific to a property of your custom type (is it null ?), or not (for rules that involve many properties for instance). The description of a rule contains a message that can be displayed to the end user (like "This field is required").

The library predefines a set of useful rules (like NotNullRule, StringLengthRule, RegexRule...). These rules can also be specified as attributes. And there is an adapter that allows to integrate the Enterprise Library Validation Application Block in Data Rules.

As previously stated, Data Rules is used by Data Access to add validation capability to our business objects. It is also used by Data Activities to enforce business rules in our data flow.

In the future, we can imagine to create our DSL to design our rules, and why not store some of them in a configuration file.

Next time, I will try to summarize the vast subject of Data Access.