Game Development Reference
In-Depth Information
The entity object and EventArgs class exist in a separate assembly from the rest of the application,
so that the assembly containing the views does not have to reference the object model assembly.
The example has three sample views, each of which displays the SimpleEntity data
in a different way. The beauty of the Model-View-Controller paradigm is that the
object model does not care about the views, so the user interface code is decoupled
from the business logic. We can also add or remove views without breaking the
object model.
Earlier in this chapter, I gave a very brief overview of how the root level of the
Microsoft Word object model is designed. The accompanying example has a sim-
ilar approach to the Application object, except it is called ObjectHost so that I do not
have to override the type name used by the System.Windows.Forms.Application class.
namespace SampleApp.ObjectModel
using Entities;
public class ObjectHost
The full source code for this class is available on the Companion Web site.
You probably noticed the EnhancedBindingList class. This class is an inherited ver-
sion of the BindingList collection that exists in System.ComponentModel . This class is
a generic collection template just like List<T> , except it supports event notifica-
tions for when the data in the list changes. These events are used to notify the
views of changes to the data. Unfortunately, the delete event for BindingList does
not store a reference to the object being deleted; it only references the index where
the object used to be stored.
I did not want to have an associated list of references to return the deleted object,
so I added an override for the RemoveItem method so I could store a reference to the
object being deleted. The following code describes the EnhancedBindingList collection.
Search Nedrilad ::

Custom Search