What should you know about object / relational mapping
Even being a new technology, there are already some object/relational mapping applications for Microsoft.NET.
We will try here to underline what should you know, and why, about object/relational mapping techniques and tools, and of course what you should absolutely avoid and why. For more questions contact us.
- Object / relational mapping application should not be intrusive, that means you should not be forced to inherit from some base classes, define custom attributes in your model (code) or program according to some naming conventions. Persistency should be transparent and should not impose design or coding constraints on the model. Developers don't want to maintain database code or persistency related API in their models either. Most tools today are quite intrusive, making your code not portable between different mapping tools or even different mapping configurations (migration scenario). Since .NET does not support multiple inheritance, when you use an intrusive mapping framework you cannot inherit from existing standard .NET classes like "System.ComponentModel.Component" or "System.EnterpriseServices.ServicedComponent", cutting out your project from many possibilities and development patterns. While DADO Solution® can be used in a completely non-intrusive way (you create your objects just inheriting from "System.Object" or what class you want), it also allows to create different mappings, for example one for a legacy database and one for a new database schema, using the same object model and front-end. DADO Solution® provides a set of base classes for common business objects (ES: Codes, filters, etc.) you can inherit from, but you are not forced to.
- Avoid absolutely code generators. Some object/relational mapping tools are in reality code generators, that means they generate C# or VB.NET source code which represent your objects and handle the mapping of them on relational structures. Together with being very intrusive and in most cases supporting very little mapping capabilities, these tools make your source code more complex (you must distinguish and maintain your code and the generated one), difficult to support and in most cases newer versions of the tools are incompatible with the previous generated code. An upgrade to another vendor without rewriting completely or in great part your application becomes in most cases impossible. DADO Database Mapper® also includes a code generator wizard, but this is simply generating classes with properties and not database access code or persistency code. It's particular useful for fast prototyping or to create your starting model, and is absolutely not a requirement.
- Object / relational mapping applications should support persistency by different means. While most tools support only persistency on tables, in an enterprise scenario we will have objects created through queries on views and persisted through stored procedure calls. This allows to extend database logic and since stored procedures are pre-compiled, to increase performance. DADO Database Mapper® can map to tables, view, stored procedures, sub-tables, joined tables, etc..
- Object / relational mapping should have different way of caching. DADO Solution® allows to defined a different cache for every object type, from the "FullCache" mostly for configuration objects to the "VolatileCache" for high volatile objects. This allows to tune your application for best performance and minimum network traffic. Against with a cache you can define for every object type an expiration time, after which the object will be reloaded anyway. In the query expression you can also force an object to reload, indipendently from the cache status or configuration.
- Object / relational mapping should support distributed and replicated databases. DADO Solution® allows to define an unlimited number of databases which are handled and coordinated automatically by the framework. This allows to reuse existing databases (with existing applications) or distribute the data load on different database servers. The coordination of distributed queries and persistency is handled transparently, including distributed transactions handling.
- Object / relational mapping should support most disparate type of mappings. While most applications support just simple mappings like 1 object - 1 table and 1 property - 1 field, DADO Database Engine supports many type of mappings, from direct mapping (1 property in 1 field) to 1:1, 1:n, n:m mappings, enumeration mappings (one object value mapped to a different field value), one object serialized in one field, sub-objects on the same table or view, one object on more tables or views, different fields as an array property and so on. Together with a wide variety of mappings, DADO Solution® provides a simple and intuitive set of interfaces to extend the system with your most desperate legacy mappings.
- Object serialization should be configurable. While most tools today work just getting and setting the public properties via .NET reflection, there should be for performance reasons a way to avoid it. If no custom serialization is implemented, DADO Solution® also uses reflection, but still allows to create your own serialization. Performance in object materialization increase of a factor of 3.