Sophie

Sophie

distrib > Fedora > 15 > i386 > by-pkgid > 864d1c3c3cd8df4e3a2692faf8776e05 > files > 713

db4o-doc-7.4-2.fc13.i686.rpm

<html>
  <head>
    <META http-equiv="Content-Type" content="text/html; charset=utf-8">
    <title>Delegates And Events</title>
    <link rel="stylesheet" type="text/css" href="../../../style.css">
  </head>
  <body>
    <div class="CommonContent">
      <div class="CommonContentArea">
        <h1>Delegates And Events</h1>
<p><font color="#990000">This topic applies to .NET version only</font>  <br></p>
<p><span name="cs_wiki_filter" csw_filters="net"></p>
<p>Db4o rules for delegate fields are very straightforward:&nbsp;<b>delegates are simply not stored.</b><br><br>Events and delegates are generally used for binding user interface elements&nbsp;and domain models together. The Db4o team felt that not storing&nbsp;delegate fields by default was more appropriate than opening&nbsp;what could potentially be a very nasty can of worms&nbsp;(just think of a text box bound to a Customer.Changed event).<br><br>After careful thought we can easily add delegate persistence to our&nbsp;domain model by either installing translators for the delegate types&nbsp;of interest or reconnecting the necessary objects upon activation&nbsp;using callbacks.<br><br>For details see the specific chapters on&nbsp;<a href="../translators.html" class="wikiLink">Translators</a> and&nbsp;<a href="../callbacks.html" class="wikiLink">Callbacks</a>.<br><br></span><br></p></div>
    </div>
    <div id="footer">
					This revision (8) was last Modified 2007-05-07T09:36:25 by Tetyana.
				</div>
  </body>
</html>