New products from Crainiate
As technical director and development manager at Crainiate, I can tell you this is the most exciting time at the company yet. We've just launched the 4th version of our flagship diagramming product which redefines the diagramming control workspace after 2 years of hard work. We plan to release version 4.1 with even more features and improvements this quarter. Version 4.1 will support user rotation of shapes (usefull when you are placing objects such as office furniture on a diagram), improved Connector features such as line jumps, animation events, post rendering properties such as metal and glass effects and added Ruler control features. We also hope to add a stencil design tool to Diagram Studio.
In the background however, we are also working on an amazing new technology, called ObjectBases, which I'd like to share for the first time here. Crainiate was originally started to bring to market a vision of a component driven and object orientated model for the entire development process, not just the the front end where most component companies concentrate their current efforts. Today there is no significant reuse in the the other 2 tiers (or n tiers) of the typical business application programming model, the business layer, and the database layer. Tools and methodolgies are fragmented. Completely differing and complex skill sets are required to build an enterprise n-tier application. Knowledge of soap/remoting and object programming is required for the business tier and database and sql design skills with advanced database, sql and stored procedure design and development skills needed to create a scallable and performant back end system.
At the moment you have some tools that try to fix the problem by mapping objects to relational database systems, by generating code that creates the select, edit, update, delete code in a business object and mapping that to a SQL table. These tools have come from the Java community and are generally known as ORM (Object Relational Mapping) and there are some pretty good implementations out there. However, some or all of the problems faced when using these tools are:
- No support for reuse of objects in other systems.
- No mechanism for database object inheritance
- Relies on SQL database design and implementation skills
- Doesnt promote or enforce good database design.
- No mechanism for the intial deployment and updating of databases (or other storage) to clients
- Doesnt significantly speed up the n-tier development process, the same effect could be achieved by cutting and pasting code between classes
- Requires code change or regeneration to use a different storage layer, or uses slower generic access via OLEDB.
- No support for non-relational storage such as XML.
- No defined way of allowing interaction between other systems.
- Uses code generation which doesnt allow for an evolvingand changing system.
Introducing the ObjectBases Framework
ObjectBases plans to turn this development paradigm on its head by providing developers one place to design, reuse and deploy their business data objects - the Visual Studio (or other) development environment which we all know and love. An ObjectBases object will have methods and properties that will mean it knows how to create and update its own storage (either in a relational database, or in a file such as an XML Document) meaning you wont have to define the properties of an object in business layer, whilst someone else duplicates the effort creating a sql database table. A simple Person object may look like this
public class Person: Entity
{
//Property variables
private int _Id;
private string _FirstNames;
private string _LastNames;
[PersistKey]
public virtual int Id
{
get
{
return _Id;
}
set
{
_Id = value;
}
}
[Persist]
public virtual string FirstNames
{
get
{
return _FirstNames;
}
set
{
_FirstNames = value;
}
}
[Persist]
public string LastNames
{
get
{
return _LastNames;
}
set
{
_LastNames = value;
}
}
By marking some or all of the properties of the object with the Persist attribute you will enable the StorageProvider you have chosen to create or locate storage for each instance of an object of this type that you create. When using a MSSQL Provider, a database table will be created if one does not exist and a row added for each object - an XML provider may create a new element in the Person.xml document.
Because the Person class is based on the Entity class, common methods such as Load, Update, Create, Delete and Validate are already available. You can use these methods as soon as you have created the object, or override them to add your own custom business logic. Intellisense will show you all the available properties and methods, without having to use recordset field names or column numbers, or having to keep xml mapping files between ado datasets and business objects.
Groups of objects are managed using the ObjectSet class, which is based on a generic collection. You call deal with collections of business objects in the same way as you deal with other object collections in the .NET framework. We may also add an ObjectReader class, to iterate rapidly through a collection of objects in a cursor-like manner without having to load vast numbers of objects in memory.
You can also create objects based on the Relationship class. These classes exist to provide links between other entities. A CustomerAddress class could define the relationship between a Customer and an Address. In ObjectBases, the relationship between objects is as important as the entity and it has the same support for creation and deletion, and allowing you to add properties that describe the relationship, such as the number of letters sent to the customer at this address.With support for generics, you also have intellisense support for related objects and methods. The relationship object will allow you to view all addresses for a customer using a simple Children method, you wont need to write any code or create any database layer logic to achieve this. Objects from different systems can be related to each other, even if you dont have the source for one or both objects.
The feature I like most is that you can then inherit from a Person class, and create a Customer, an Employee and a User object without having to code any of the fields ever again. You can focus on adding properties and logic specific to these objects, and inherit both the structure, and the relationships from the base Person class. You will be able to update the a customer's Address record becuase you have already created a relationship between Person and Address.
Behind the scenes, a sql storage provider may be creating the tables, managing the constraints, indexing the required columns and writing the stored procedure code to access the data logic. When deploying the system to a customer, the tables, constraints and procedures are created or modified the first time they are used as soon as a new Assembly is recognised. Older versions of an assembly will be supported as long as they can match the new assembly.
Further Information
The great news is that the ObjectBases Framework will most likely be free for development and deployment. It has been designed for .NET Framework 2.0 and will ship with MS Sql and Xml providers. Documentation wil l exist to allow other developers to create additional providers for other storage layers, such as MS Access, Oracle etc.
Visual tools to create ObjectBase system diagrams, predefined Objectbase libraries and ObjectBase reporting tools will also be available for purchase in the near future after release of the framework.Currently the ObjectBases Framework is at an inhouse beta stage, with a working XML Provider.
Ill be updating my blog with more news. If you wish to join the beta program, please post or contact.