The road to Salamanca

To content | To menu | To search

Tag - Data Rules

Entries feed - Comments feed

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 !

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.

Wednesday, August 20 2008

Visiting Salamanca

Fundamentally, Salamanca is designed around three sets of libraries :Architecture

  1. Data Access is the easiest to explain in a few words : think of it as (yet) an (other) (ORM) library. Why another ? We believe that there is not nor will ever be a perfect solution for this problem ; call us "ORM limitations acceptors". Our belief is that an ORM solution has to be designed to fulfill a specific set of issues under a specific set of constraints (which definitely sounds like a product line to me). After all, if you want to go around and around in circles without going anywhere, you are more likely to win the race with a formula one car. If you want to drive home, you will be better off with a standard commercial car : it has been designed for average roads, and priced accordingly. This library will help us handle business specific data in a (DAL).
  2. Data Activities is a library that helps define the business data lifecycle into a specific layer. The latter is a which lies at the core of our architecture : it manages business data, drives the HMI, and as such acts as a perfect (?) .
  3. Data Rules is a validation framework. It will be used to implement our business rules in our activities transitions and our data.

These libraries represent the fundamental abstractions around which our applications will be built. Best practices can be documented around their use, that can be written with our own (DSLs). We have defined two DSLs so far :

  1. SDML (Salamanca Domain Modeling Language) : this language will help us structure our data in order to implement our DAL. But more than that, it will help us create reusable states for our activities, or reusable component for data edition (user controls in Windows Forms for instance). Its representation is very close to a UML Class Diagram.
  2. SAML (Salamanca Activities Modeling Language) : this will help us define our activities. Activities reuse concepts defined in a SDML model. Its representation is inspired by the (BPMN).

Implementing an application with our libraries once the models are properly defined should be quite straightforward. So straightforward that we will be gain a lot by creating two tools that will greatly enhance our productivity :

  1. A Modeler : a graphical tool that will help us visually model our application and serialize it in SDML and SAML formats.
  2. A Generator : a tool that will implement our best practices and take our model as input, in SDML and SAML formats, and generate our C# code. Though it is imaginable to generate a whole functioning application, the developer will have the possibility to customize the generated code to make it more usable, or implement parts that could not be modeled. Usually, developers will ... develop a usable HMI on top of the generated code.

As for now, the libraries are quite in an advanced state, the DSLs definition is in progress and the tools are part of our to do list.