⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 tiofp documentation - what is an object persistence framework.htm

📁 tiOPF 面向对象的数据库持久层持久层开发的框架
💻 HTM
📖 第 1 页 / 共 3 页
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0056)http://www.techinsite.com.au/tiOPF/Doc/1_WhatIsAnOPF.htm -->
<HTML><HEAD><TITLE>tiOFP Documentation - What is an object persistence framework?</TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312"><!-- InstanceBegin template="/Templates/TechInsite_Template.dwt" codeOutsideHTMLIsLocked="false" --><!-- InstanceBeginEditable name="doctitle" --><!-- InstanceEndEditable --><!-- InstanceBeginEditable name="head" --><!-- InstanceEndEditable --><LINK 
href="tiOFP Documentation - What is an object persistence framework_files/TechInsite.css" 
type=text/css rel=stylesheet>
<META content="MSHTML 6.00.3790.1830" name=GENERATOR></HEAD>
<BODY>
<SCRIPT type=text/javascript>function Go(){return}</SCRIPT>

<SCRIPT 
src="tiOFP Documentation - What is an object persistence framework_files/MainMenu_TechInsite.js" 
type=text/javascript></SCRIPT>

<SCRIPT 
src="tiOFP Documentation - What is an object persistence framework_files/HVMenu.js" 
type=text/javascript></SCRIPT>
<NOSCRIPT>Your browser does not support script</NOSCRIPT> 
<DIV id=Container><IMG height=75 alt="" 
src="tiOFP Documentation - What is an object persistence framework_files/Banner01.jpg" 
width=600 border=0> 
<TABLE cellPadding=5 valign="middle">
  <TBODY>
  <TR>
    <TD>
      <DIV id=pageheader1>TechInsite</DIV></TD>
    <TD>
      <DIV id=pageheader2>Home of the TechInsite Object Persistence 
      Framework<BR>Melbourne, Australia</DIV></TD></TR></TBODY></TABLE>
<HR>

<TABLE>
  <TBODY>
  <TR>
    <TD>
      <DIV id=HMenu style="POSITION: relative"></DIV></TD></TR></TBODY></TABLE><BR>
<HR>
<!-- InstanceBeginEditable name="Page title" -->
<H1>1. What is an OPF?</H1><!-- InstanceEndEditable --><!-- InstanceBeginEditable name="Page body" -->
<H1>Introduction</H1>
<P>In this chapter we look at what an object persistence framework (OPF) is and 
how it can help you build better business applications. We examine some of the 
problems inherent in applications that are built using the RAD (rapid 
application design) approach that Delphi encourages, and examine how an OPF can 
help reduce these problems.</P>
<P>We take a look at the design requirements of an OPF as specified by the 
Jedi-Obiwan project (an open source project to build the ultimate OPF for 
Delphi), and Scott Ambler (a respected writer on the subject of OPFs). We will 
contrast these requirements with the design of the TechInsite OPF and see how 
the framework addresses (or fails to address) these requirements.</P>
<P>The next section of this chapter discusses some of the problems with using 
Delphi’s RAD approach to build complex business applications. We then have a 
high level look at some of the requirements of an OPF and see who the current 
version of the tiOPF meets (or fails to meet) these requirements.</P>
<H2>RAD vs OPF</H2>
<P>(Rapid Application Design vs Object Persistence Framework) There is no 
question that the tools that come with Delphi can be used to build a database 
application very, very quickly. The power of the combination of the BDE Alias, 
TDatabase, TQuery, TDataSource and TDBEdit is incredible. The problem is that 
with every TDatabase or TQuery you drop on a TDataModule, you have tied yourself 
more closely to the BDE. With every TDBEdit added to a form, you have coupled 
yourself to that particular field name in the database.</P>
<P>The alternative is to roll your own persistence layer. This is hard work and 
will cost you hundreds of hours of work before it comes close to matching the 
functionality of what comes out of the box with Delphi. However, if the business 
case justifies this work, then the results can be stable, optimised, versatile 
and extremely satisfying to build.</P>
<H2>Three ways to build an application</H2>
<P>Consider this statement: There are three possible ways to build an 
application: </P>
<P><STRONG>RAD – Rapid Application Design</STRONG>. The process of dropping data 
access components onto a TDataModule, and hooking them up to data aware controls 
like the TDBGrid and TDBEdit at design time. Good for simple applications, but 
if used for complex programs, can lead to an unmaintainable mess of spaghetti 
code.</P>
<P><STRONG>OPF – Object Persistence Framework.</STRONG> Design a business object 
model using UML modeling techniques, the implement the model by descending 
business classes from your own abstract business object and abstract business 
object list. Write a family of controls to make building GUIs easier, then 
design some mechanism for saving these objects to a database, and reading them 
back again.</P>
<P><STRONG>Hybrid – Using RAD techniques, but adding a middle layer.</STRONG> 
Continue using the best of what RAD can offer (the huge selection of GUI 
controls that are available), but implement some sort of mddle layer using 
Delphi’s components as they come out of the box. The TClientDataSet that comes 
with Delphi 5 Enterprise is a prime candidate as the starting point for this 
middle layer.</P>
<P>The rest of this chapter discusses the pros and cons of RAD and OPF, then the 
rest of this document discusses the implementation of an OPF. A chapter on using 
the hybrid approach would be worth wile and is on my personal to do list.</P>
<H2>Four problems with RAD business applications</H2>
<P>A couple of month ago there was a discussion on the Australian Delphi User 
Group’s (www.adug.org.au) mailing list on the topic of developing your own 
persistence framework, versus using RAD and data aware controls. Many posts to 
the mailing list where made and everyone seamed to have a strong opinion one way 
or the other. Delphi developers either love RAD and hate OPF, or hate RAD or 
love OPF. Several argued that the hybrid approach was worth a look but the 
argument was generally polarised. As the discussion on the list continued, most 
agreed that there was a place for RAD and data aware controls in single tier 
file based applications, or client server prototypes. Most of the experienced 
client/server developers who contributed to the discussion agreed that there was 
no room for RAD and data aware controls in sophisticated client server 
applications.</P>
<P>Here are four problems with RAD and data aware controls.</P>
<OL>
  <LI><STRONG>Tight coupling to the database design.</STRONG> One of the biggest 
  problems with using RAD and data aware controls is that the database layer is 
  very tightly coupled to the presentation layer. Any change to the database 
  potentially means that changes must be made in many places throughout the 
  application. It is often hard to find where these changes must be made as the 
  link from the data aware controls in the application to the database are made 
  with published properties and the object inspector. This means that the places 
  to make changes can not be found with Delphi’s search facility. When data 
  aware controls are used, the amount of checking by the compiler of you code is 
  reduced. This means that some bugs may not be detected until run time, or may 
  not be detected at all until the user navigates down a path the developer did 
  not foresee. Developing a persistence framework allows you to refer a data 
  object’s values by property name rather than by using a DataSet’s FieldByName 
  method. This gives greater compile time checking of the application and leads 
  to simplified debugging.<BR>
  <LI><STRONG>RAD and data aware controls create more network traffic.</STRONG> 
  It is a simple exercise to drop a few data aware controls on a form, connect 
  them to a TDataSource, TQuery and TDatabase then load the DBMonitor 
  (C:\Program Files\Borland\Delphi4\Bin\sqlmon.exe) and to watch the excess 
  network traffic they create.<BR>
  <LI><STRONG>Tight coupling to vendor specific database features.</STRONG> At 
  the simplest level, all databases accept the same SQL syntax. For example a 
  simple, select * from customers will work for all the systems I have come 
  across. As you become more sophisticated with your SQL, you will probably want 
  to start using some special functions, a stored procedure or perhaps an outer 
  join, which will be implemented differently by each database vendor. Data 
  aware controls make it difficult to build your application so it can swap 
  database seamlessly.<BR>
  <LI><STRONG>Tight coupling to a data access API.</STRONG> The BDE allows us to 
  swap aliases when you want to change databases, but what if you want to switch 
  from BDE data access, to ADO, IBObjects, Direct Oracle Access (DOA), 
  ClientDataSet or our own custom data format? (This is not the fault of the 
  data aware controls, but is still a problem with the component-on-form style 
  of developing.) A custom persistence framework can be designed to eliminate 
  this tight coupling of an application to a data access API. </LI></OL>
<P><SPAN class=Heading_PageTitle>Summary: RAD vs. OPF</SPAN></P>
<TABLE cellSpacing=1 cellPadding=1 border=1>
  <TBODY>
  <TR class=Normal>
    <TD vAlign=top width=121>
      <P><STRONG></STRONG>&nbsp;</P></TD>
    <TD vAlign=top width=149>
      <P><STRONG>Advantages </STRONG></P></TD>
    <TD vAlign=top width=173>
      <P><STRONG>Disadvantages </STRONG></P></TD>
    <TD vAlign=top width=149>
      <P><STRONG>When do I use? </STRONG></P></TD></TR>
  <TR class=Normal>
    <TD vAlign=top width=121>
      <P><STRONG>Data aware controls </STRONG></P></TD>
    <TD vAlign=top width=149>
      <UL>
        <LI>Good for prototypes. 
        <LI>Good for simple, single tier apps. 
        <LI>Good for seldom used forms, like one-off setup screens that may be 
        used to populate a new database with background data. </LI></UL></TD>
    <TD vAlign=top width=173>
      <UL>
        <LI>Higher maintenance and debugging costs. 
        <LI>Higher network traffic. 
        <LI>Limited number of data aware controls in Delphi (but plenty if you 
        use InfoPower or other libraries) 
        <LI>Can not be used to edit custom file formats, registry entries or 
        data that is not contained in a TDataSet. 
        <LI>Harder to develop your own data aware controls than regular 
        controls. 
        <LI>Difficult to make work when the database does not map directly into 
        the GUI ie, a well normalised database. 
        <LI>Difficult to make extensive reuse of code. </LI></UL></TD>
    <TD vAlign=top width=149>
      <UL>
        <LI>Low end customers (small businesses with few user). 
        <LI>Throw away prototypes. 
        <LI>Data maintenance apps that my customers will not see. 
        <LI>Systems where I have total control over the database design. 

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -