tiofp documentation - what is an object persistence framework.htm

tiOPF 面向对象的数据库持久层持久层开发的框架

        <LI>When the user wants the app to look and perform as if it were 
        written in VB. </LI></UL></TD></TR>
  <TR class=Normal>
    <TD vAlign=top width=121>
      <P><STRONG>Persistence framework </STRONG></P></TD>
    <TD vAlign=top width=149>
      <UL>
        <LI>Good for complex applications. 
        <LI>Lower network traffic. 
        <LI>Lower total cost of ownership. 
        <LI>When the database is storing non text data like multi-media, or 
        perhaps scientific data which must be manipulated with complex 
        algorithms. 
        <LI>Decouple GUI from database. </LI></UL>
      <P> </P></TD>
    <TD vAlign=top width=173>
      <UL>
        <LI>More skilled development team. 
        <LI>Higher up front development cost. 
        <LI>Many reporting tools take input from a TDataSet. Some extra code 
        would be needed to connect the persistence framework to the reporting 
        tool. 
        <LI>Must re-build what comes out of the box with Delphi . </LI></UL></TD>
    <TD vAlign=top width=149>
      <UL>
        <LI>High end (corporate) customers with many users where performance is 
        important. 
        <LI>Systems that have complex data models that I have little control 
        over. 
        <LI>Systems that require a TreeView, ListView look and feel. 
        <LI>Systems that must be database vendor independent. 
  </LI></UL></TD></TR></TBODY></TABLE>
<H2>Some technical requirements of an OPF</H2>
<H2>Source of information</H2>
<P>These design notes have been taken from two sources:</P>
<P>&#8226; The Jedi-Obiwan project, to build an open source object persistence 
framework in Delphi; and</P>
<P>&#8226; Scott Ambler’s writings on object persistence frameworks.</P>
<P>These sources combine to give a much more comprehensive overview of the 
requirements of an OPF than I could write. In each case, the design requirement 
is listed (in normal font), then some notes on how the tiOPF addresses (or fails 
to address) this requirement is made in <EM>Italics</EM>.</P>
<H2>How the tiOPF compares with Jedi-Obiwan OPF requirements</H2>
<P>The specification, along with other design and discussion documents, and a 
mailing list for the Jedi-Obiwan project can be joined at <A 
href="mailto:[e-mail]">mailto:[e-mail]</A></P>
<OL>
  <LI><STRONG>Object Persistence.</STRONG> The framework must allow for the 
  storage and retrieval of data as objects. The framework must support the 
  storage and retrieval of complex objects, including the relationships - e.g. 
  inheritance, aggregation and association - between different 
  objects.<BR><BR><EM>The storage and retrieval of data as objects, with their 
  relationships such as inheritance, aggregations and association is well 
  met.</EM><BR>
  <LI><STRONG>Object Querying.</STRONG> The framework must provide a mechanism 
  for querying the object storage and retrieving collections of objects based on 
  defined criteria. The framework must support a standard object querying 
  language – e.g. Object Constraint Language (OCL) [5] or Object Query Language 
  (OQL) [6].<BR><BR><EM>Querying is supported at two levels. A group of objects 
  can be retrieved from a database using what ever query language the database 
  used (eg SQL). Once a list of objects has been read, there are methods on the 
  abstract list class which allow filtering and querying. This filtering and 
  querying can be achieved in two ways. A query class can be created to scan for 
  matches; or a query can be run using RTTI to extract a property value by name 
  and compare it to a passed parameter.</EM><BR><BR><EM>There is no OCL beyond 
  what is described above.</EM><BR>
  <LI><STRONG>Object Identity.</STRONG> All objects persisted within the 
  framework must be uniquely identified using an Object IDentifier (OID). OIDs 
  must be supported within legacy environments and as such the OID mechanism 
  must be sufficiently flexible enough to used to identify data objects even 
  when the underlying storage mechanism doesn’t explicitly support such 
  identification.<BR><BR><EM>The abstract base persistent object has a property, 
  OID of type TOID. In the framework, this is an Int64, which means the second 
  part of this requirement is not met. An OID factory would have to be 
  introduced. This suggests all objects must support the IOID interface, or 
  descend from a parent class with OID as a property.</EM><BR>
  <LI><STRONG>Transactions.</STRONG> The framework must support transactions, 
  satisfying the ACID Test set out by the Object Management Group [ 
  http://www.omg.org ]. A transaction should be Atomic (i.e. it either happens 
  completely or doesn’t happen at all), its result should be Consistent, 
  Isolated (independent of other transactions) and Durable (its effect should be 
  permanent).<BR><BR>To this end the framework must support the same sort of 
  object transaction operations as the operations found in typical SQL databases 
  implementations, e.g. Commit, Rollback, etc.<BR><BR>The framework supports 
  transactions as provided by a SQL database. For example, you can make some 
  changes to a group of objects and attempt to save them to the database. If the 
  database commit is successful, the objects’ state will be set from dirty, back 
  to clean. If the commit is not successful, the objects’ state will not be 
  changed so further editing can take place. <BR><BR>This is a kind of two phase 
  commit.<BR><BR><EM>There is no support for transactions beyond what is 
  provided by the SQL database being used for the persistence.</EM><BR>
  <LI><EM>XML Data Sources.</EM> The framework must be able to persist data 
  object in repositories other than SQL databases. In particular the framework 
  must support the storage and retrieval of data objects from XML 
  files.<BR><BR><EM>XML Data sources are well supported.</EM> <BR>
  <LI><STRONG>Legacy Data.</STRONG> The framework must provide mechanisms for 
  converting data stored in legacy databases into data objects useable by Delphi 
  applications, as well as be able to store data objects within legacy systems. 
  <BR><BR>The framework may also provide mechanisms for persisting legacy 
  business objects – that is, business objects that predate the existence of the 
  framework. In this case the framework may require some modification of 
  existing business objects but this must not be onerous.<BR><EM><BR>Support for 
  legacy databases is excellent. The developer has full control over how objects 
  and databases are mapped.</EM><BR>
  <LI><STRONG>Heterogeneous Data Sources.</STRONG> The framework must be able to 
  work with data objects from a variety of data sources at run time. The 
  representation of business objects in repositories must be independent from 
  the business objects themselves, in that on object in one data repository 
  stored in one repository may be stored in an alternative repository without 
  any changes apparent to the object from the perspective of the application 
  using it.<BR><BR>The framework must be able to work with data objects of the 
  same class existing in separate repositories. The framework should also enable 
  the association of data from heterogeneous sources, i.e. data from a variety 
  of legacy or new database systems.<BR><BR><EM>The tiOFP allows for multiple 
  persistence layers (or different types of database) to be connected at the 
  same time. There may be several instances of each database type loaded at the 
  same time. </EM><BR>
  <LI><STRONG>Reporting Tools.</STRONG> The framework must support conventional 
  reporting technologies, either by providing supporting classes for common 
  reporting tools (e.g. ReportBuilder) or by storing data using database schemas 
  that are readily accessible by reporting tools.<BR><BR><EM>Export of a 
  collection of objects to HTML, XML and CSV is provided via the XML and CSV 
  persistence layers. There is also the TtiDataSet wrapper that makes a tiOFP 
  list of objects look like a TDataSet.</EM> <BR>
  <LI><STRONG>Versioning and Version Migration.</STRONG> The framework may 
  support the versioning of objects, that is to say: the framework may allow for 
  different versions of the same class of business object to be maintained 
  within the same repository.<BR><BR>The framework must support the migration of 
  data when class interfaces change (e.g. when a new version of an application 
  is released). The framework must support the process of modifying existing 
  data to fit updated business object metadata.<BR><EM><BR>Object versioning is 
  possible when coded by the developer.</EM><BR>
  <LI><STRONG>Performance Optimizations.</STRONG> The framework must be able to 
  be optimized. That is, in performance critical environments where the 
  knowledge of a skilled DBA is required for an application to perform 
  successfully, repository-based optimizations must be available to applications 
  using the framework.<BR><BR><EM>This requirement is well met. The developer 
  can either use the auto generated SQL framework, or can code the SQL himself. 
  This can become quite complex as managing the persistence of a single object 
  takes four SQL statements (Create, Read, Update, Delete), and four persistence 
  classes to handle the mapping between the object to be saved. This is 
  simplified by using a tool called the tiSQLManager, which is used to store the 
  SQL in the database. A family of classes is written to interact with this SQL 
  that has been abstracted out of the application.</EM><BR>
  <LI><STRONG>Separation of Business Logic and User Interface.</STRONG> The 
  framework must separate user-interface and business logic code, clearly 
  defining the points of integration between the two. Its design must take on a 
  “layered” approach, where high-level complex functionality builds upon 
  simpler, lower level services.<BR><BR><EM>Business logic, presentation logic 
  and the persistence layer are strictly separated. For example, if we have a 
  TCustomer class, there will probably be a unit called Customer_BOM.pas (for 
  business logic), Customer_Cli.pas (for client side, presentation logic) and 
  Customer_Srv.pas (for persistence logic).</EM><BR>
  <LI><STRONG>Separation of Object Data and Object Metadata.</STRONG> Object 
  metadata must be stored within the framework (i.e. within a supported 
  repository) and not encapsulated within the business objects 
  themselves.<BR><BR><EM>There has been little attempt to separate meta data. 
  Extensive use is made of RTTI if meta data is required. There has been one 
  situation where I required automatically generated SQL, so there are a family 
  of classes which map classes to tables and properties to fields.</EM><BR>
  <LI><STRONG>Object Data Standard Compliance.</STRONG> Developers of the 
  framework may elect to design the framework to meet the compliance 
  requirements of the ODMG’s Object Data Standard 3.0 [6]. It is possible that 
  ODS compliance may be implemented as an extension to the framework, but 
  neither this, nor compliancy in general has been 
  decided.<BR><BR><EM>No.</EM><BR>
  <LI><STRONG>Operating Environment.</STRONG> The framework must support 
  persistence under a variety of deployment models, specifically Standalone, 
  Client-Server and n-Tier.<BR><EM><BR>Yes.</EM><BR>
  <LI><STRONG>Database Schemas / Multi-vendor Databases.</STRONG> The nature of 
  the framework must allow for any number of database schemas to be used and so 
  must be extensible enough to allow end-users (Delphi developers) to extend the 
  system to match their own persistence requirements. Default schemas may be 
  defined for illustrative, testing or typical persistence requirements but 
  should not be considered the only schemas usable within the framework. 
  <BR><BR>While arguments for a “pure” (i.e. database-vendor neutral) 
  persistence solution carry weight, the performance cost and legacy-data issues 
  outweigh any gains enjoyed from having a single, simple implementation. Given 
  that the framework must be extensible by third parties there is nothing 
  preventing the implementation of a vendor-neutral extension to the framework,