"Anatomy of the PetShop" III: PetShop data Access Layer Message processing _ self-study process

Third, the PetShop data access Layer message processing

In the system design, in addition to security, business and other issues to give enough attention, performance is an unavoidable problem, especially a B/s structure of the software system, must fully consider the access, data flow, server load problems. To solve the bottleneck of performance, in addition to the hardware system upgrades, the rationality of software design is particularly important.

As I mentioned earlier, layered structure design can affect the performance of data access to some extent, but it is almost negligible compared to the benefits it brings to designers. To provide the performance of the entire system, you can also start from the optimization of the database, such as the use of connection pooling, indexing, optimization of query strategy, etc., such as in the PetShop in the use of the database cache, for large amounts of data on the order data, The order and inventory databases are created separately for them by means of a sub library. And in the software design, the more useful way is to use multithreading and asynchronous processing mode.

In PetShop4.0, Microsoft Messaging Queue (MSMQ) technology is used to complete asynchronous processing, using Message Queuing to temporarily hold data to be inserted so that data access provides access performance because it does not require access to the database, and for data in the queue, Wait for the system to be idle and then process it, eventually inserting it into the database.

The message processing in PetShop4.0 is mainly divided into the following parts: Message interface imessaging, message Factory messagingfactory, MSMQ implementation msmqmessaging and Data spooler application Orderprocessor.

From the modular point of view, PetShop fulfills the principle of "interface-oriented design", separates the interface of message processing from the implementation, and encapsulates the message to create the object through the Factory mode to achieve the goal of loose coupling.

Because only the processing of orders in PetShop uses asynchronous processing, in the message interface imessaging, only one Iorder interface is defined, and its class diagram is as follows:

In the implementation of the message interface, given that there will be other data objects in the future extension that will use MSMQ, a base class for queue is defined to implement the basic operations of message receive and send:

Public virtual Object Receive ()
{
 try
 {
  using ' message = queue. Receive (timeout, transactiontype)) return message
   ;
 catch (messagequeueexception Mqex)
 {
  if (MQEX). MessageQueueErrorCode = = messagequeueerrorcode.iotimeout)
   throw new TimeoutException ();
   Throw
 }
}
public virtual void Send (Object msg)
{
  queue. Send (msg, transactiontype);
}

Where the queue object is the System.Messaging.MessageQueue type, which is used to store the data. MSMQ queues are a durable queue, so you do not have to worry about the loss of order data due to user uninterrupted underground orders. The timeout value is set in Petshopqueue, and orderprocessor periodically scans the order data in the queue based on the timeout value.

In the Msmqmessaging module, the order object implements the interface Iorder defined in the Imessaging module, and it inherits the base class Petshopqueue, which is defined as follows:

public class Order:petshopqueue,
 
the implementation code for the PetShop.IMessaging.IOrder method is as follows: public
new OrderInfo Receive ()
{
 //This is involves in distributed transaction and need Automatic transaction type
 Base.transactiontype = Mes sagequeuetransactiontype.automatic;
 Return (OrderInfo) (message) base. Receive ()). Body;
}

Public OrderInfo Receive (int timeout)
{
 base.timeout = timespan.fromseconds (convert.todouble (timeout));
 return Receive ();
}

public void Send (OrderInfo ordermessage)
{
 //This method does not involve in distributed transaction and Optimi Zes performance using single type
 base.transactiontype = messagequeuetransactiontype.single;
 Base. Send (ordermessage);
}

Therefore, the final class diagram should read as follows:

Note that in the receive () method of the Order class, the receive () virtual method of the parent class Petshopqueue is overridden with the new keyword instead of the override keyword. Therefore, if you instantiate an object like this, the Petshopqueue receive () method is invoked instead of the receive () method of the subclass order:

Petshopqueue queue = New Order ();
Queue. Receive ();

From the design point of view, because petshop adopt the principle of "interface-oriented design", if we want to create an order object, we should adopt the following way:

Iorder order = New Order ();
Order. Receive ();

In view of the possible changes in the implementation of Iorder, PetShop still leverages the factory pattern and encapsulates the creation of Iorder objects with specialized factory modules:

In class Queueaccess, the Createorder () method is used to create the correct Iorder type object using reflection technology:

public static PetShop.IMessaging.IOrder Createorder ()
{
 string className = Path + ". Order ";
 return PetShop.IMessaging.IOrder) Assembly.Load (path). CreateInstance (ClassName);
}

The value of path is obtained through the configuration file:

private static readonly string path = configurationmanager.appsettings["ordermessaging"];

In the configuration file, the value of the ordermessaging is set as follows:

<add key= "ordermessaging" value= "petshop.msmqmessaging"/>

The use of Factory mode for the creation of objects is easy to invoke in the business layer, such as orderasynchronous classes in BLL modules:

public class Orderasynchronous:iorderstrategy
{  
 private static readonly PetShop.IMessaging.IOrder Asynchorder = PetShop.MessagingFactory.QueueAccess.CreateOrder ();
 public void Insert (PetShop.Model.OrderInfo order)
 {
  asynchorder.send (order);
 }

Once the implementation of the Iorder interface changes, this implementation will allow the customer to modify the configuration file only, without the need to modify the code, so that the assembly can avoid recompilation and deployment, so that the system can be flexible to respond to changes in requirements. For example, to define a specialorder that implements the Iorder interface, you can add a new module, such as Petshop.specialmsmqmessaging, while the class name is still order, then we only need to modify the Ordermessaging value in the configuration file:

<add key= "ordermessaging" value= "petshop.specialmsmqmessaging"/>

Orderprocessor is a console application, but it can be designed as a Windows Service as needed. Its purpose is to receive order data from message queues, and then insert it into orders and inventory databases. It utilizes multithreading technology to achieve the goal of improving system performance.
in an Orderprocessor application, main function main is used to control threads, while the core execution task is implemented by Method Processorders ():

private static void Processorders () {//The transaction timeout should is long enough to handle all of orders in the BA

 tch TimeSpan tstimeout = Timespan.fromseconds (convert.todouble (transactiontimeout * batchsize));
 Order order = New Order ();
  while (true) {//Queue timeout variables TimeSpan datetimestarting = new TimeSpan (DateTime.Now.Ticks);

  Double elapsedtime = 0;

  int processeditems = 0;

  ArrayList queueorders = new ArrayList (); using (TransactionScope ts = new TransactionScope (transactionscopeoption.required, tstimeout)) {//Receive the Order s from the queue for (int j = 0; J < batchsize J + +) {try {//only receive more queued orders if th Ere is enough time if (elapsedtime + queuetimeout + transactiontimeout) < Tstimeout.totalseconds) {Qu Eueorders.add (order.
     Receivefromqueue (queuetimeout)); else {j = batchsize;//Exit loop}//update Elapsed Time ElapsedTime = new TimespAn (DateTime.Now.Ticks).
    Totalseconds-datetimestarting.totalseconds;
    The catch (timeoutexception) {//exit loop because no more messages are waiting j = batchsize; }//process the queued orders for (int k = 0; k < Queueorders.count; k++) {order.
    Insert ((OrderInfo) queueorders[k]);
    processeditems++;
   totalordersprocessed++;
  }//batch Complete or MSMQ receive timed out ts.complete (); Console.WriteLine ("Thread Id + Thread.CurrentThread.ManagedThreadId +") batch finished, "+ Processeditems +" it

 EMS, in "+ elapsedtime.tostring () +" seconds. ");}

First, it gets the order data in the message queue through the public method Receivefromqueue () of the PetShop.BLL.Order class, and puts it into a ArrayList object. The Insert method of the PetShop.BLL.Order class, however, is then inserted into the order and inventory database.

In the PetShop.BLL.Order class, instead of directly executing an insert order, the Insert () method of the Iorderstrategy interface is invoked:

public void Insert (OrderInfo order)
{
 //Call credit card procesor
 Processcreditcard (order);

 Insert the Order (a) synchrounously based to Configuration
 Orderinsertstrategy.insert (order);

Here, a policy pattern is applied, and the class diagram looks like this:

In the PetShop.BLL.Order class, the configuration file is still used to dynamically create Iorderstategy objects:

private static readonly PetShop.IBLLStrategy.IOrderStrategy orderinsertstrategy = Loadinsertstrategy ();
private static PetShop.IBLLStrategy.IOrderStrategy Loadinsertstrategy ()
{
 //Look up which strategy to use from C Onfig file
 String path = configurationmanager.appsettings["orderstrategyassembly"];
 String className = configurationmanager.appsettings["OrderStrategyClass"];

 Using the evidence given in the config file load the appropriate assembly and class return
 (PetShop.IBLLStrategy.IO Rderstrategy) Assembly.Load (path). CreateInstance (ClassName);
}

Because Orderprocessor is a separate application, it uses a different configuration file than PetShop and is stored in the application's app.config file, where the Iorderstategy configuration is:

<add key= "orderstrategyassembly" value= "PetShop.BLL"/> <add key= "OrderStrategyClass"
PetShop.BLL.OrderSynchronous "/>

Therefore, the process of inserting an order asynchronously is shown in the following illustration:

In addition to being used for asynchronous processing, Microsoft messaging Queue (MSMQ) technology is primarily a distributed processing technology. In the distributed processing, an important technical element is the processing of the message, but in the System.Messaging namespace, the message class has been provided, which can be used to carry messages, on the premise that the sender and receiver of the message should have a uniform interface specification on the data definition.

The application of MSMQ in distributed processing has already been implemented in the projects I am involved in. When developing a large system for a car manufacturer, the distributor, dealer, as a. NET client, needs to pass data to the central administration, and the data will be used by Oracle's EBS (e-business system). Because the Distributor Management system (DMS) uses the C/s structure, the database is SQL Server, and the EBS database of the auto manufacturer Management Center is Oracle. This involves the transfer of data between the two systems.
The implementation architecture is as follows:

First dealer data is passed through MSMQ to MSMQ Server, at which point data can be inserted into the SQL Server database, and FTP is used to transfer data to a dedicated file server. IBM's EAI Technology (Enterprise application integration, Enterprise application itegration) is then used to periodically write files from file servers, using interface specifications to the EAI database server, and eventually to the Oracle database of EBS.
The above architecture is a typical distributed processing structure, and the core of technology implementation is MSMQ and EAI. Since we have defined a unified interface specification, after a file is formed through a message queue, the data at this time has nothing to do with the platform, making the. NET platform, the Distributor management system can integrate with Oracle's EBS to complete data processing.

The above is the PetShop data Access Layer message processing part of the whole content, hope to give you a reference, but also hope that we support cloud habitat community.