The Microsoft .NET platform is quickly finding market share in consulting companies and large IT shops that build object-oriented enterprise applications. Its object-oriented languages, Web page event-driven programming model, and ease of development all make .NET a powerful platform on which to build object-oriented systems.
Most of these systems, however, have their carefully designed object-oriented architecture stopped cold when it hits the database and data-access programming objects. Traditional relational database management systems (RDBMS) simply don't lend themselves very well to object-oriented programming. Thirty percent of an application's code alone is used for mapping an application's object-oriented design to the database's relational model.
There is another way, however, and it goes back to a technology that started in the 1990s. Object databases (ODBMS) are a solution to the tedium of relational database mapping code. Though not for every project, object databases are a powerful element in an enterprise architect's bag of tricks.
This article introduces you to Matisse, one of the first object databases to release a .NET binding. It will show a very simple example application using both a relational database and an object database to illustrate the differences in design.
Relational Databases
The relational database is, of course, well known by most architects and developers working with typical enterprise, line-of-business, or e-commerce applications. A workhorse of the industry since the mid-seventies, the RDBMS is well understood and is easily adapted to a variety of applications. Developed around the idea that information can be stored in flat two-dimensional tables and then related to other pieces of data in other tables through keys, the relational database is a proven technology.
Figure 1 - A typical relational database design
The RDBMS was initially developed by Ted Codd at IBM in the early 1970s, and it reached a commercial breakthrough point in the 1980s. Companies such as Oracle, IBM, Sybase, Microsoft, and others each developed their own versions of the database.
The data-manipulation language SQL greatly spurred along the widespread acceptance of the relational database, and it now helps account for the near universality of the database as the back-end store for an application. A developer can go from project to project and from database vendor to database vendor and not require extensive ramp-up time. The methods used to design databases and to access and manipulate information in them is fairly standard across companies and projects. This standardization gives the software-development industry a stable baseline on which applications can be built.
That said, there is a significant amount of work required to use a relational database. The database itself must be designed and administered by a very skilled architect. Large databases from Oracle or Microsoft require dedicated resources to administer them, and the hardware and licensing costs associated with operating these databases are high. From an application-development perspective, the cost of using a relational database is considerable. The clean object model that the architect designs for the project and that developers code against simply can't be stored in a relational database. Some code must be developed to provide a mapping between the object architecture and the data. Some estimates place the amount of code required simply to interact with the database at 30 percent of the total code in a project.
Enterprise Application Using Relational Databases
Development of an object-oriented enterprise application with a relational database typically follows a familiar pattern:
After requirements have been gathered and turned into a design-ready format, a class diagram is made that lists the high-level objects required by the system.
Figure 2 - A typical UML class diagram
The object developers begin work based on that model, writing application code to implement those classes in the class diagram.
The database architect is tasked with turning this Unified Modeling Language (UML)-class diagram into a valid database design. The designer may create an entity relationship diagram as an intermediate step between the class diagram and the final database implementation.
A relational structure is constructed which models the class diagram as closely as possible. Identity columns are added for each entity; foreign key columns and constraints are added for each association on the class diagram; and the model is "flattened out" to support many-to-many relationships, as necessary.
At this point the database has been created, which more or less supports the class diagram created by the application designers. The database architect can begin working with the system architect on the next major phase of the project, the object/relational mapping.
The mapping between the objects in the class diagram and the tables in the relational database is a tedious but unavoidable task. The elegant class design in the class diagram can be perfectly suited to the application being built, with proper use of inheritance and polymorphism greatly decreasing the amount of work needed to build the system. The business users have bought into this idea and like the clean design showing a clear path to implementation for their business functionality. What a surprise for them when they learn that the objects being written won't be able to save their information for days or weeks!
The method for mapping the data flow between the objects and the database can vary, but a typical design is:
Database stored procedures are created for the basic CRUD (Create, Retrieve, Update, Delete) operations of each table.
One data-access class is created per database table to manage database interaction. A good open-source generator like LLBLGen at http://www.sd.nl/software/ can save a tremendous amount of time here by automatically generating all of the required stored procedures and data-access objects.
Some method of passing information between the Data Access objects and the Business objects must be designed. In the .NET world, the Microsoft DataSet object can be a real time -saver because the strongly typed versions of the DataSets can provide some method of safety in the error-prone tasks of referencing column names. If DataSets aren't used, custom collections can be used to marshal the data.
At this point, there will be at least four stored procedures per database table, one class for each table, and a large framework of code to be maintained when the unavoidable changes happen to the class and database designs.
Beyond the issue of maintenance and code management, there is the paradigm shift that occurs when the database is accessed. Developers accustomed to working with objects and properly partitioned application functionality will suddenly be marshaling data into arrays and DataSets and making strangely procedural-looking function calls.
Figure 3 - Mapping from the Data Access object to the Business object
Is there a better way than having 30 percent of your application's code do nothing more than pass information into and out of arrays? The methods above will support the construction of a successful application, but there is a different way that may be appropriate for some projects and teams.
Object Databases
The object database (ODBMS) is that different way. Object databases moved beyond the research labs and into commercial applications in the mid 1990s and have steadily grown in acceptance. Offering a fundamentally different way of designing the persistence layer for an application, object databases are an often-overlooked element in object-oriented systems.
The core idea behind object databases is that you use your data in the same fashion as you store it. Developers like this! There is no mental paradigm shift between the time the data is used for a business calculation and the time it is persisted. The developers simply use their objects as indicated in the class diagrams, and the objects know how to persist themselves at the end of an operation.
Object databases typically do not have the large overhead in terms of code maintenance and administration that a relational database carries. At the same time, typical relational database features such as transactions, concurrency, atomicity, online backups, and other important administrative tasks are supported by most object databases.
Major vendors in the field include Matisse Software Inc., Objectivity Inc., Poet's FastObjects, Computer Associates, and eXcelon Corporation. There are a few open-source implantations as well. The industry is constantly changing, and at the moment it is mostly Java focused. Matisse is the only major vendor to presently offer a .NET binding to its database, though FastObjects (a spinoff from Poet) is readying its for release shortly.
With an object database, developers and designers don't concern themselves with exactly how data is stored, as in the relational process shown above. Instead of the seven steps outlined above for constructing an application with a relational database as the persistence method, the object database requires these steps:
A class diagram is made which lists the high-level objects required by the system.
The object developers begin work based on that model, writing application code against the class diagram.
The object model is turned into a new database schema for use by the object database. The methods for doing this vary by vendor, but generally a simple text-based UML language is used to create the schema.
There is no need to spend time designing a separate model for the database. The class diagram created in step one can usually be used to construct an object database.
At this point in the relational system above, the system architect and database designer needed to construct a mapping scheme to transfer information between the objects in the application and the database. With an object database, this tedious and time-consuming process is history; the objects you have already created will know how to interact with the database. Whether it is through inheriting a database base class or some other object-oriented means, the development process is shorter and cleaner.
Another benefit of an object database is performance. If the data in your system is complex, hierarchical, or requires many joins in the relational tables, then an object database will perform better by several orders of magnitude. Since the object database stores objects as they exist in your code, with all of their relationships and nested hierarchies, there is no expensive joining or searching for data spread across many normalized tables.
Matisse
Since this article's purpose is to show object-oriented development in the .NET world, choosing an object database that natively supported .NET was an easy requirement. The hard part came in finding such a database, but the hard work paid off. Matisse Software's Matisse database, found at www.matisse.com, is an excellent object database with a long history of industrial use, and it is perfect for our purposes here.
In production since 1990, Matisse has been used in a wide area of domains from nuclear power plants to video conferencing to full text searching on the Web. The biggest draw of Matisse is that it inherently provides both an object database and a relational interface in the same product. It offers ANSI SQL support for relational access to the database, while simultaneously offering the native object support typical of other object databases. The system is like other object databases in that it requires little administration and supports traditional relational features such as dynamic schema evolution, database replication, backups, database partitioning, and even stored procedures.
To develop an enterprise application using Matisse, the system designers will begin by loading Matisse with the object schema. This is done in an object-oriented way by using Matisse's Object Definition Language (ODL). The language is the standard object definition language as pushed by the Object Data Management Group (http://www.odmg.org/), and is heavily influenced by the standards-setting Object Management Group's Interface Definition Language (IDL). It is quite easy to take a standard UML class diagram and turn it into ODL.
Figure 4 - Specifying the object database schema with ODL
It is also possible to use standard SQL or the Rational Rose binding (also from Matisse) to initially create the database.
After the database is created the designer will need to add the code necessary for the application's business objects to interact with Matisse. Matisse comes with a generator that will generate C# code against the schema in a database. It will create one class per file with all of the class's attributes and relationships already built. The application designers can then either add code to these generated classes or, perhaps better yet, inherit from them to keep things that much cleaner.
Figure 5 - Matisse will generate C# code to access the UML attributes
After this, the interaction with the database is essentially finished. The developers can begin adding functionality to the business classes. No large framework of relational mapping classes needs to be built, and the code size will stay manageable.
Example Application Description
This application is one I recently helped write for an e-commerce company to illustrate where an object database can be appropriate. This application is a partner integration system between the e-commerce company and its suppliers. The supplier partners need to use this ASP.NET application to manage the products they supply to the e-commerce company. We used Microsoft SQL Server 2000 and .NET.
The information the partners are managing is hierarchical in nature. Each partner supplies multiple products to the e-commerce company across different predefined categories. The categories and products fit into a hierarchy that must be maintained across all different suppliers.
Figure 6 - Tree view of the example application's nested hierarchies and products
Now, of course, one level of hierarchy does not require an object database. With a foreign key from the Product table to the Category table, the relational database can easily accommodate that level of hierarchy. An additional foreign key for the Category table to itself can handle the nested categories, though it does require some fancy coding at either the business or presentation layer to properly display the categories on the page.
It's the concept of Product types in this application that makes an object database interesting. The products in the categories more or less contain the same type of information -- name, weight, SKU, etc. Some products, however, require the storage of more information. Apparel products need information on Level Costs, for example. Apparel products are priced based on the number of products ordered by the end user. The price is lower as the quantity ordered increases. An additional database table is needed to support this, and again this is not difficult in a relational database. However, only Apparel products, and not Book or Electronic products, need this. Additionally, there are subcategories of Apparel, such as Shirts or Pants. Shirts have a property named "IsButtoned," and Pants have a property named "InseamLength." We used a separate property table for things like this in the original application, but it required special code in several layers to get it right.
My new object database is going to take care of that for me in a much more elegant fashion. We will create a database in Matisse to more closely follow the class structure of the design. First we need the Categories. This is done quite simply with the following ODL:
Figure 7 - The Category class's ODL
Next we need our Products. Instead of one table for our Products and then separate property tables, as in the previous design, we'll create a Product base class and then create separate subclasses for each of the Product types. That way we can very simply store the appropriate data at the right places. There should be very little application code needed to track down additional data for a Product depending on its type. Likewise, the Level Cost data is stored along with the Apparel products.
Figure 8 - The inherited Electronic and Book products
So what does this buy us? Quite a bit. We can now operate on the data in the database exactly as we operate on the objects in our system. When we create a tree view, we don't need to pull information out of the database, map it to DataSets or arrays, and then bind it to the tree. We can simply walk down a collection of objects.
The code to accomplish this is deceptively simple because:
the relationships between the data are stored with the data.
the database makes it very easy to distinguish among common types of data differing only by a classification.
The code to get the products associated with a given category is:
Figure 9 - The code to walk down the associations between classes is easy because Matisse builds the relationships into the objects.
Likewise, the code for displaying different information depending on the product type is easy to understand:
Figure 10 - Getting the type of product is as simple as checking the object type.
It continues like this throughout the application. If I am contacted again by this client for another similar application, I can suggest another way of designing it, one which would take less time, would be easier to understand for maintenance down the road, and would ultimately cost less.
Working with Both an ODBMS and a RDBMS
By now you may have decided an object database is right for your organization. It allows you to stay in the object-oriented paradigm; it offers performance improvements for complex or hierarchical data; and it might be cheaper as well. What could be wrong with this?
You guessed it -- all of your existing relational databases. There is a thought in the IT world that once data makes it into a system, it is there to stay. So the millions of relational databases in the world are going to stay around, and any application using an object database must find ways to interface with it. How is this possible?
With a hybrid object database like Matisse there is an easy solution -- the SQL interface the database already supports. Any third-party reporting or data-migration tool should be able to interact with Matisse and the relational database together, transferring data between them. If your object database does not support a SQL interface, then your options are more limited, and some custom coding may be needed to build an interface between the systems. I can envisage Web Services as coming into play here.
Another issue that goes more to application design is that of multitier architectures and the logical separation of the database. With a relational database you can construct a three-tier (or more commonly now, multitier) architecture with the database at the back, a data-access tier in front of it, and then multiple business tiers. Using an object database on a project can change this. An object database can remove the necessity of data-access and data-marshaling tiers. At the same time, an object database could simply replace a relational database if an application has already been designed with appropriate abstraction tiers. The presentation and business tiers of an application should be able to accommodate this database change, as long as they were designed with database abstraction in mind.
Conclusion
Object databases have a definite place in enterprise applications. Though not as standardized as relational databases and requiring a leap of faith from customers and stakeholders, object databases simply fit in with object-oriented development techniques. Developers will cease to write and maintain dozens of classes and hundreds of stored procedures simply for data marshaling, and the effect of having no paradigm shift between object-orientation and procedural programming will keep programmers focused on the important stuff -- the business logic.
There are disadvantages to object databases and there are applications for which an object database may not be a good fit. The lack of standardization among vendors over things such as query languages, schema languages, and programming language bindings can be an issue. If one vendor goes out of business, it can be a significant effort to rewrite the application to use a new object database. With a relational database, this can be an easier task, depending on the use of stored procedures and other proprietary vendor functionality. Also, the lack of a SQL-compliant interface will hurt when standard reporting or other data tools are used.
Matisse, on the other hand, addresses these issues by providing standard SQL compliance and support for the virtually standard Object Definition Language. Its rich support of C#, VB.NET, Java, C++, XML, and Interactive Software Engineering Inc.'s Eiffel make it an easy product with which to integrate, and its ease of administration make it a viable option on a .NET project.
There is, however, even another middle ground besides hybrids like Matisse between pure object databases and relational databases. By using an object/relational mapping framework, object-oriented developers can stay in the comfortable realm of objects and still access the universality and excellent reliability of relational databases. An object/relational framework might just give you the best of both worlds while tying you to neither. There will be more on that in a future article. For now, go have some fun and use Matisse on a test project. Your objects will thank you.
About the Author
Matt Culbreth is a Senior Consultant with Intellinet Corporation, based in the Atlanta area. Intellinet, the southeast's only four-time Microsoft Gold Certified Partner, provides application-development and infrastructure consulting services throughout the southeast. Intellinet builds enterprise .NET systems using object-oriented development techniques and their custom process, a best-of-breed development methodology combining the leading agile techniques in the business.
Matt resides in Marietta, Georgia, with his wife Angela. He has been involved with .NET since the Beta releases, and has implemented several enterprise .NET applications. He previously worked for several years as an independent consultant through his own consulting firm, and developed and marketed one of the first native ADO.NET provider to the MySQL database.
Proposion N2N connects Microsoft .NET applications to Lotus Notes and Lotus Domino databases. This ADO.NET managed data provider allows you to perform blindingly fast queries and updates of Notes data from ASP.NET pages, .NET web services, Windows, or Mobile applications. An innovative SQL-like query language leverages the unique features of Notes and makes collaborative software accessible to relational database programmers.
Multi-tiered applications can quickly become unmanageable if they are not organized logically, consistently, and correctly. Solomon Shaffer of Intellinet Corporation explains one way to structure object-oriented n-tiered applications to be effective, simplistic, and highly maintainable. [Read This Article][Top]
Collections are a vital element of any object-oriented architecture. This article, by Luther Stanton of Intellinet Corporation, introduces collections, looks at some of the benefits and potential drawbacks of using custom collections versus built-in collection-like elements, and then provides a discussion of interfaces and implementations. [Read This Article][Top]
Mailing List Want to receive email when the next article is published? Just Click Here to sign up.
