What is csmodule in CS, the event listening system implemented by csmodule? As we know, when the system is large, it must be complicated. Many internal events in the system need to be intercepted and understood by the interconnected modules. We need to develop the CS system. In fact, we mainly write event-oriented code for a large number of events in the Process of CS internal process execution. For example, to ensure that exceptions occur in the system, we can receive them in a sensitive manner and handle exceptions in a specific "security zone". For example, we sometimes monitor a post. If a new post needs to be notified, it is acceptable if it is hard-coded, But if more than one system needs to be notified of the new post, hard encoding obviously does not meet the requirements. In this way, a coordination mechanism is required to introduce a notification model, internal events can be securely and orderly transferred to the Event-related processing part through this mechanism, which is implemented through csmodule in CS. Csevent defines most events in the system. Events that contain users, posts, sections, groups, postcategories, ratings, favorites, exceptions, search, userinvitations, and other objects. However, every event calls the corresponding event function of the csapplication instance. For example, search events: public static void presearch (searchquery query) {csapplication. instance (). executepresearch (query);} public static void postsearch (searchresultset results) {csapplication. instance (). executepostsearch (results);} these events need to be triggered in a specific code stream, and these events will be transferred to the csapplication instance. Csapplication is a singleton mode and caches instances through cscache. Its instance function: internal static csapplication instance () {const string key = "csapplication"; csapplication APP = cscache. get (key) as csapplication; If (APP = NULL) {lock (Sync) {APP = cscache. get (key) as csapplication; If (APP = NULL) {csconfiguration Config = cscontext. current. config; xmlnode node = config. getconfigsection ("communityserver/csmodules"); APP = new csapplication (); If (node! = NULL) {foreach (xmlnode N in node. childnodes) {If (N. nodetype! = Xmlnodetype. comment) {Switch (N. name) {Case "clear": app. modules. clear (); break; Case "Remove": xmlattribute removenameatt = n. attributes ["name"]; string removename = removenameatt = NULL? Null: removenameatt. value; If (! Globals. isnullorempty (removename) & App. modules. containskey (removename) {app. modules. remove (removename);} break; Case "add": xmlattribute en = n. attributes ["enabled"]; If (EN! = NULL & en. value = "false") continue; xmlattribute nameatt = n. attributes ["name"]; xmlattribute typeatt = n. attributes ["type"]; string name = nameatt = NULL? Null: nameatt. value; string itype = typeatt = NULL? Null: typeatt. value; If (globals. isnullorempty (name) {eventlogs. warn (string. format ("A csmodule cocould not be loaded. the name was not defined. type {0} ", itype)," csmodules ", 654, cscontext. current. settingsid); continue;} If (globals. isnullorempty (itype) {eventlogs. warn (string. format ("A csmodule ({0}) cocould not be loaded. no type was defined ", name)," csmodules ", 655, cscontext. current. settings ID); continue;} type = type. getType (itype); If (type = NULL) {eventlogs. warn (string. format ("A csmodule ({0}) cocould not be loaded. the type {1} does not exist ", name, itype)," csmodules ", 656, cscontext. current. settingsid); continue;} icsmodule mod = activator. createinstance (type) as icsmodule; If (mod = NULL) {eventlogs. warn (string. format ("A csmodule ({0}) cocould not be loaded. the type {1} Cocould not be instantiated ", name, itype)," csmodules ", 657, cscontext. current. settingsid); continue;} Mod. init (app, n); app. modules. add (name, MoD); break ;}}} cachedependency Dep = new cachedependency (null, new string [] {csconfiguration. cachekey}); cscache. max (Key, app, DEP) ;}} return app;} the above Code loads the module (csmodule) icsmodule mod = activator that needs to listen to the event by analyzing "communityserver/csmodules. createinstance (typ E) as icsmodule; here, the instantiated icsmodule uses reflection. This statement also initializes the listening time of the module. The event listening event uses the Add Remove method, which allows the event broadcasting mechanism to call the init function immediately after obtaining the csmodule instance. This type of function mainly carries an instance of the current csapplication, and carry communityserver/csmodules to configure the XML Node object of the current node. Generally, the Inti function should use the following code to hook events: Public void Init (csapplication CSA, xmlnode node) {CSA. userknown + = new csusereventhandler (csa_userknown);} That is, to notify csapplication, this module will receive an event. Then how does csapplication manage these events and distribute them? When + = is used inside the init function to listen to events, the listener callback function is stored: public event csusereventhandler userknown {Add {events. addhandler (eventuserknown, value);} remove {events. removehandler (eventuserknown, value) ;}} store the callback function handle to the hash table by adding remove, so that multiple callback functions of one event are allowed. In this way, we can see that in CS, the event stream is aggregated through the csapplication instance and distributed to multiple modules registered in the init function through the event mechanism, the distribution path is: Event source --- csapplication instance-csmodule1 | ------------ csmodule2 | ----- csmodule3 ..... What are the benefits of this design? 1. Events are generated and processed separately. 2. events can be broadcast, and multiple listeners can process events. In addition, such processing can be implemented through configuration files. To achieve "light programming and re-configuration", but also to achieve loose coupling.
Add an event and have a layout structure reference. It facilitates system expansion and expansion.
