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.