Server| Notes | Design This time we'll look at the application of design patterns in Issuevision, issuevision mainly uses observer (Observer) mode and command mode. See you today observer (Observer) The application of pattern in issuevision plays an important role in issuevision.
The "gang" Gof is a one-to-many relationship between defined objects that define the Observer (Observer) pattern, and when the state of an object changes, all objects that depend on it are notified and automatically updated.
As can be seen from the definition, the OBSERVER (Observer) pattern logically requires two sets of objects to be implemented. First of all, it needs to have a publisher (Publish), also known as the observed target (Subject) (It is customary to call it a target Subject, and we call it the target after all Subject The other is the Subscriber (Subscribe), customarily known as the Observer (Observer). A target object corresponds to multiple observer objects, and when the target object changes, all the Observer objects registered in the target object are notified and automatically updated.
In the application development process, the user interface and business logic are often required to separate and delineate clear boundaries. Because applications require rapid changes to the user interface and do not have a knock-on effect on other parts of the application, the business logic changes and requires that all changes be unrelated to the user interface. Observer ( Observer) is the most common design pattern for solving this problem, and it is very useful for dividing clear boundaries between objects in the system.
The best illustration of this form, the viewer (Observer) (Table objects, histogram objects, and pie-chart objects) relies on the subject of the data object, so all changes to the data object subject are notified. But they don't know each other's existence, The Table object does not know the existence of other table objects or other column objects. For data object subject can have any number of observers who can be notified when the subject object changes, and synchronize their state with the subject:
OK, so much for the concept, let's take a look at the implementation of the Observer (Observer) model. The realization of the Universal Observer (Observer) mode I'm not going to say this anymore, You can refer to Gof design patterns and Java and schema, and so on. We focus on the implementation of the Observer (Observer) pattern in the. NET Framework.
. NET Framework introduces delegates and events that provide an updated, more powerful way to implement the Observer (Observer) pattern. (For more on delegates and events, refer to the documentation). If you are unfamiliar with delegates and events, implementing the Observer (Observer) pattern requires a lot of work (as in Java). Below I will be the implementation of the issuevision to briefly tell.
There are two files ISubject.cs and IObserver.cs under the Patterns folder in Issuevision. They define the interface between the target (Subject) object and the viewer (Observer) object, and the code is as follows:
ISubject.cs
Namespace Issuevision
{
Isubject is a simple marker interface that supports the implementation
Of the Observer pattern in issuevision.
public interface Isubject
{
}
}
IObserver.cs
Namespace Issuevision
{
IObserver is a simple interface that supports the implementation of the
Observer pattern in issuevision.
public interface IObserver
{
Isubject Subject
{
Set
}
}
}
You may find that these two interfaces are almost empty and nothing is defined, so what are the roles of these two interfaces? In fact, the function of defining these two interfaces is mainly coding "normalization", as long as the class implements either of these two interfaces, then the Observer (Observer) pattern is realized on behalf of this class. And obviously know who is subject, who is observer.
The Issuesubject component in Issuevision implements the Isubject interface, which is the main part of the Observer (Observer) model in Issuevision, It is also one of the most complex classes in issuevision. Let's analyze it 1.1 o ' time (of course, the analysis of the Observer (Observer) pattern):
IssueSubject.cs
public class Issuesubject:component, Isubject
First, the class Issuesubject is inherited from component and isubject, and it can be seen from here and class names that this class is implemented as a goal (SUBJECT) in The Observer (Observer) pattern. Target (Subject) object requires implementation of the observer ( Observer) Registration (register) and notification, component class is used to implement registration (register). The implementation of most goal (Subject) objects is not to store the Observer (Observer) reference directly in its own instance variable , but instead delegate this person to a single object (usually a container) the component class is a container in which the following code shows how to store a reference registration (register) of an observer (Observer) object with a component class container
Public Issuesubject (IContainer Container): this ()
{
Container.add (this);
}
Let's take a look at how it completes registration (register), first we find an observer (Observer) object implementation, Controls/issuetreeview user control is an observer (Observer) Object. It implements the IObserver interface.
Controls/issuetreeview.cs
Namespace Issuevision
{
The Issuetreeview user control implements the view selection UI for Issuevision
public class Issuetreeview:usercontrol, IObserver
{
The method of public virtual Isubject Subject//isubject interface
{
Set
{
M_subject = (issuesubject) value;
.....
}
}
The Pane/staffpane user control references this issuetreeview, and it is also an observer (Observer) object.
Pane/staffpane.cs
Namespace Issuevision
{
public class Staffpane:usercontrol, IObserver
{
....
Private Issuetreeview itvviews;
Private IContainer components = null;
Iobserver.subject
Public Isubject Subject
{
Set
{
Itvviews.subject = (issuesubject) value;
}
}
Call this user control code in MainForm.cs as follows:
Private Issuesubject m_issuesubject = null;
.....
M_issuesubject = new Issuesubject (this.components); Calling the Issuesubject constructor
Panestaff.subject = M_issuesubject;
This observer (Observer) object is registered to the target (Subject) object by calling the Issuesubject constructor. (through the container of the Container.add ())
This completes the first step of the OBSERVER (Observer) pattern, registering the Observer (Observer) object. Let's look at the second step, how the Target (Subject) object notifies the Observer (Observer) object
This requires the use of delegates and events. Come back and watch Issuesubject.
IssueSubject.cs
public class Issuesubject:component, Isubject
{
#region Delagate and Event Declarations
.......
public delegate void Conflictdatachangedeventhandler (object sender, EventArgs e);
public delegate void Lookupdatachangedeventhandler (object sender, EventArgs e);
Conflictdatachanged changes when a conflict is resolved, or new conflicts are
Detected.
Public virtual event Conflictdatachangedeventhandler conflictdatachanged;
Lookupdatachanged is raised when lookup data are downloaded from the server
Public virtual event Lookupdatachangedeventhandler lookupdatachanged;
......
In Issuesubject the delegates and events are declared, and the Observer (Observer) object registers these events, then when Issuesubject changes and activates an event, all the Observer (Observer) objects are notified of the change, Thus activating the corresponding processing.
And look at Controls/issuetreeview.cs.
Namespace Issuevision
{
The Issuetreeview user control implements the view selection UI for Issuevision
public class Issuetreeview:usercontrol, IObserver
{
.....
Private TreeView trvviews;
Private Issuesubject m_subject = null;
Private IContainer components;
The method of public virtual Isubject Subject//isubject interface
{
Set
{
M_subject = (issuesubject) value;
Registering Issuesubject events and handing them to the relevant methods for handling events
M_subject. Lookupdatachanged + = new Issuesubject.lookupdatachangedeventhandler (this. subject_lookupdatachanged);
M_subject. Conflictdatachanged + = new Issuesubject.conflictdatachangedeventhandler (this. subject_conflictdatachanged);
}
}
Finally, these events are activated in Issuesubject.
if (lookupdatachanged!= null)
{
Lookupdatachanged (this, eventargs.empty);
}
}
With such a simple few steps, the Observer (Observer) pattern is achieved. NET Framework provides a great simplification of the implementation of the schema.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.