Domain and Query aspects
Regardless of how entities are implemented, queries can be performed over them.
This implies that the entities and their relationships are precisely described in a domain model (namespace Eldorado.Object.Domain) and that queries can be composed and checked against the domain model (namespace Eldorado.Object.Query). Precisely, how a query is to be executed is out of the scope of this aspect (though the semantics of the operators ARE in this scope).
The query language is inspired by the relational theory and includes operators like join and project. This means that
Disconnected aspect
The repository where the objects ultimately reside generally is not the application's memory itself, but an external storage like a DBMS. Consequently there is a boundary to cross in order to access the data. Since this boundary crossing has a cost, EldorADO.NET provides mechanisms to help developers optimize boundary traversals: (namespace Eldorado.Object.Disconnected)
Combining the preloading facilities with the query-language-with-joins is part of the anwser to overcome performance issues generally associated with object persistence layers.
Entity aspect
Managing entities with their unique identities is both poweful in some scenarios and unnecessary time-consuming in others. So is this aspect separated from other considerations (namespace Eldorado.Object.Entity).
Entities are stored in a local storage (IObjectStorage). An ObjectContext serves as a bridge between the local storage and one or several RemoteSource objects.
Relational aspect
A RDBMS is one possible implementation for a remote source. Great care has been taken to decouple this aspect from the other ones, so that relational persistence is not the only possible option, and that the queryable and disconnected aspects can be reused in other scenarios.
The O/R mapping (Eldorado.Object.Relational) leverages a database-independant API (Eldorado.Relational) which allows relational queries to be composed out of basic relational operators - at a lower level than object operators - and to generate the corresponding SQL based on drivers targeting particular RDBMS engines. This is what we call the 2-level mapping schema: by leveraging the "morphism" between the object and the relational operators, we can factor out many operations before even thinking about the resulting concrete SQL.
The O/R mapping is extensible: it is based on factory classes that are declared and configured in a XML file.
Interface | Description |
---|---|
IObjectSource | Interface supported by components capable of executing ObjectQuery queries. |