Business Entity Components
In 2006, my company began a large migration to three-tier architecture based on Microsoft .NET. A key component of the strategy included the migration to an ORM (Object-Relational Mapping) engine. By 2006, open-source and commercial ORM’s were available for .NET; however, they often had serious constraints particularly in their ability to map to complex schemes, serialize from a middle-tier and support globalized data.
In 2003, I had implemented our own ORM (before commercial and open-source alternatives were available) in order to support our Web Services initiative. Even though new options were available, we felt our best option was to continue to extend and update our proprietary ORM since it had numerous advantages that specifically benefited our product.
By the Spring of 2007, our ORM (referred to as the “Business Entity Components”) supported:
- Reading/writing business entities that mapped to multiple tables.
- Code generation of highly-efficient entity objects.
- Metadata synchronization with the database schema regarding property data types and constraints.
- Support for business entities that could be represented in multiple languages. The BEC returned results in the preferred language of the user with automatic fallback to a default language.
- Support for caching.
- Support for complex queries using an XPath-like notation. The query language supported complex predicates and full-text index awareness.
- Efficient bulk loading and lazy loading.
- Metadata reflection.
- Support for composite object identifiers.
- Support for abstracting and obfuscating physical storage identifiers.
- Robust, hierarchical serialization between tiers.
- Rich serialization via SOAP and Web Services.
- Automatic generation of rich developer documentation.
- Employer
- SumTotal Systems
- Roles
- Lead Software Architect, Development Lead
- Style
- Commercially-available
- Technology
- C#/.NET 3.0
