Reading XML, reflection, and calling object Methods

I have never done anything similar before, and reflection is only limited to copying attributes. I asked people everywhere, but I didn't fully meet my requirements. Look at my problem first:

I don't know when to start. At the business layer and when designing, my business objects and their methods are written separately in different classes and interfaces. This design seems to have a name, which is a digress. However, when a business object interacts with another business object, where should these interaction methods be written and where should they be verified? For example, there must be interactions between the two business objects in the sales orders and invoices. During the operation, the sales invoices can be generated from the sales orders, you can also create a sales invoice and fill it with the order information. My approach is to add a layer of business logic to operate these business objects and call their methods.

Another simpler example is as follows:

Import the archive write records (third-party), map the data to the Business Objects in the current domain, write the data, and return the write results. Other business processes also call methods of the same business, but the purpose and order may be different.

In this way, I am OK. However, if the operation sequence changes, we need to change the "Process" layer, change the code and recompile it. These situations occur frequently and change frequently in some business logic. In the financial accounting module previously written, the accounting rules need to be constantly changed as the organizational structure and cost allocation methods change. This is an example.

I hope that you can use XML to define the behavior of a business flow and modify the XML (or even set up an interface for the user to modify it) to make these changes. This is what I want to do.

The first thought was to use jBPM (. Net version) or Workflow Foundation, but I felt that it was useless. Some friends introduced Drools, which was not big. Then I went to stackoverflow and asked, a big brother said that I call IoC. Then I thought about how to use reflection for containers, so I can write it myself.

As mentioned above, I am not very familiar with reflection. I have made a simple experiment and can do it as follows:

<? Xml version = "1.0" encoding = "UTF-8"?>
<Rules>
<Rule name = "rule1">
<Type name = "test">
<Method name = "method1">
<Param> </param>
</Method>
<Method name = "method2">
</Method>
</Type>
</Rule>

</Rules>

Let's use this test. The object name is test. There are two methods in it. This version does not indicate the Call Sequence in XML, but it is also very easy to add (I would like to try parameter input, if the invoke and type are correct, this cannot be done ). The following is the code. The object name should have been taken from XML. I will try it. Change it if you are interested:

Using System;
Using System. Xml;
Using System. Reflection;

Namespace DynamicInvokeTest
{
Class Program
{
Static void Main (string [] args)
{
XmlDocument doc = new XmlDocument ();
Doc. Load ("Rule1.xml ");
XmlNodeList nodelist = doc. GetElementsByTagName ("type ");
Foreach (XmlNode x in nodelist)
{
If (x. Attributes ["name"]. Value = "test ")
{
Foreach (XmlNode y in x. ChildNodes)
{
If (y. Name = "Method ")
{
Console. WriteLine ("------------ Invoke now --------------");

Object [] argument = {"Hua "};
Assembly assembly = Assembly. LoadFrom ("DynamicInvokeTest.exe ");
Type type = assembly. GetType ("DynamicInvokeTest. test ");

Object obj = Activator. CreateInstance (type );
Console. WriteLine ("Class: {0}", type. ToString ());
Console. WriteLine ("Invoking method: {0}", y. Attributes ["name"]. Value );
Type. InvokeMember (y. Attributes ["name"]. Value,
BindingFlags. InvokeMethod,
Null,
Obj,
Argument );
}
}
}
}
Console. ReadKey ();
}
}

Public class test
{
Public void method1 (string I)
{
Console. WriteLine (I. ToString ());
}

Public void method2 (string name)
{
Console. WriteLine ("Hello, {0}", name );
}
}

}

You may think there is nothing, not InvokeMember. But for me, it is very useful to have this flexibility.

This is 109,000 different from the real rule engine, but I am enough.

 

 

Postscript:

I am very excited to do things I have never done, but it cannot reach the degree of practical use. I need to add a lot of things, otherwise there will be many limitations. For example, the dependency between business processes, for example, Parse and then evaluate when conditions are met, or the implementation of rule chaining. After some further searches, I found someone had done it. I used the WF rule engine but didn't use its Workflow. I will try it out later.

Http://www.richard-banks.org/2007/08/how-to-use-windows-workflow-rules.html