Shulou(Shulou.com)06/03 Report--

This article mainly shows you the "sample analysis of message processing in the PetShop data access layer", which is easy to understand and well-organized. I hope it can help you solve your doubts. Let the editor lead you to study and study the "sample analysis of message processing in the PetShop data access layer".

Message processing of PetShop data access layer

In the design of the system, in addition to paying enough attention to security, transactions and other issues, performance is also an inevitable problem, especially for a software system with Bhopper S structure. the problems of access volume, data flow and server load must be fully considered. To solve the bottleneck of performance, in addition to upgrading the hardware system, the rationality of software design is particularly important.

As I mentioned earlier, hierarchical design may affect the performance of data access to some extent, but it is almost negligible compared with the benefits it brings to designers. In order to provide the performance of the whole system, we can also start with the optimization of the database, such as the use of connection pool, establishing index, optimizing query strategy and so on. For example, the Cache of the database is used in PetShop, and for the order data with large amount of data, separate Order and Inventory databases are established for the order data with a large amount of data. In software design, a more useful way is to use multithreading and asynchronous processing.

In PetShop4.0, Microsoft Messaging Queue (MSMQ) technology is used to complete asynchronous processing, and the message queue is used to store the data to be inserted temporarily, so that the data access provides access performance because it does not need to access the database. As for the data in the queue, it will be processed when the system is idle and finally inserted into the database.

Message processing in PetShop4.0 is mainly divided into the following parts: message interface IMessaging, message factory MessagingFactory, MSMQ implementation MSMQMessaging and data background processing application OrderProcessor.

From the perspective of modularization, PetShop implements the principle of "interface-oriented design" from beginning to end, separates the interface of message processing from the implementation, and encapsulates the message through the factory pattern to create objects, so as to achieve the purpose of loose coupling.

Since asynchronous processing is only used for order processing in PetShop, only one IOrder interface is defined in the message interface IMessaging, and its class diagram is as follows:

In the implementation of the message interface, considering that other data objects will use MSMQ in future extensions, a base class of Queue is defined to implement the basic operations of message Receive and Send:

Public virtual object Receive () {try {using (Message 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 of type System.Messaging.MessageQueue and serves as a queue for storing data. The MSMQ queue is a durable queue, so you don't have to worry about the loss of order data when users place orders without interruption. When the timeout value is set in PetShopQueue, 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 inherits the base class PetShopQueue, which is defined as follows:

The implementation code of public class Order:PetShopQueue and PetShop.IMessaging.IOrder method is as follows: public new OrderInfo Receive () {/ / This method involves in distributed transaction and need Automatic Transaction type base.transactionType = MessageQueueTransactionType.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 optimizes performance using Single type base.transactionType = MessageQueueTransactionType.Single; base.Send (orderMessage);}

Therefore, the final class diagram should be as follows:

Notice that in the Receive () method of the Order class, the Receive () virtual method of its parent class PetShopQueue is overridden with the new keyword instead of the override keyword. Therefore, if the following objects are instantiated, the Receive () method of PetShopQueue will be called instead of the Receive () method of the subclass Order:

PetShopQueue queue = new Order (); queue.Receive ()

From a design point of view, because PetShop adopts the principle of "interface-oriented design", if we want to create Order objects, we should use the following ways:

IOrder order = new Order (); order.Receive ()

Considering the possible changes in the implementation of IOrder, PetShop still leverages the factory pattern to encapsulate the creation of IOrder objects with special factory modules:

In the class QueueAccess, use the reflection technique to create the correct IOrder type object through the CreateOrder () method:

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 from the configuration file:

Private static readonly string path = ConfigurationManager.AppSettings ["OrderMessaging"]

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

The reason why the factory pattern is used to take care of object creation is that it is easy to invoke it in the business layer, such as the OrderAsynchronous class in the BLL module:

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 can make the customer only need to modify the configuration file, but not the code, so that the recompilation and deployment of the assembly can be avoided, and the system can flexibly respond to the change of requirements. For example, if you 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 value of OrderMessaging in the configuration file:

OrderProcessor is a console application, but it can be designed as Windows Service according to your requirements. Its purpose is to receive the order data from the message queue and insert it into the Order and Inventory databases. It uses multithreading technology to improve the performance of the system.

In OrderProcessor applications, the main function Main is used to control the thread, while the core execution task is implemented by the method ProcessOrders ():

Private static void ProcessOrders () {/ / the transaction timeout should be long enough to handle all of orders in the batch 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 orders from the queue for (int j = 0) J < batchSize; jungle +) {try {/ / only receive more queued orders if there is enough time if ((elapsedTime + queueTimeout + transactionTimeout) < tsTimeout.TotalSeconds) {queueOrders.Add (order.ReceiveFromQueue (queueTimeout));} else {j = batchSize; / / exit loop} / / update elapsed time elapsedTime = new TimeSpan (DateTime.Now.Ticks). TotalSeconds-datetimeStarting.TotalSeconds } catch (TimeoutException) {/ / exit loop because no more messages are waiting j = batchSize;}} / / process the queued orders for (int k = 0; k < queueOrders.Count; kits +) {order.Insert ((OrderInfo) queueOrders [k]); processedItems++; totalOrdersProcessed++;} / / batch complete or MSMQ receive timed out ts.Complete () } Console.WriteLine ("(ThreadId" + Thread.CurrentThread.ManagedThreadId + ") batch finished," + processedItems + "items, in" + elapsedTime.ToString () + "seconds.");}

First, it takes the order data in the message queue through the public method ReceiveFromQueue () of the PetShop.BLL.Order class and puts it into an ArrayList object, then calls the Insert method of the PetShop.BLL.Order class to insert it into the Order and Inventory databases.

In the PetShop.BLL.Order class, instead of directly inserting the order, the Insert () method of the IOrderStrategy interface is called:

Public void Insert (OrderInfo order) {/ / Call credit card procesor ProcessCreditCard (order); / / Insert the order (a) synchrounously based on configuration orderInsertStrategy.Insert (order);}

Here, a policy pattern is applied, and the class diagram is as follows:

In the PetShop.BLL.Order class, you still use the configuration file to create the IOrderStategy object dynamically:

Private static readonly PetShop.IBLLStrategy.IOrderStrategy orderInsertStrategy = LoadInsertStrategy (); private static PetShop.IBLLStrategy.IOrderStrategy LoadInsertStrategy () {/ / Look up which strategy to use from config 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.IOrderStrategy) Assembly.Load (path) .CreateInstance (className);}

Because OrderProcessor is a separate application, it uses a configuration file that is different from PetShop and is stored in the application's App.config file, where the configuration for IOrderStategy is:

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

Microsoft Messaging Queue (MSMQ) technology is not only used for asynchronous processing, but also a distributed processing technology. In distributed processing, an important technical element is the processing of messages, and in the System.Messaging namespace, Message classes have been provided, which can be used to carry messages. On the premise that the sender and receiver of messages should have a unified interface specification in data definition.

The application of MSMQ in distributed processing has been implemented in the project I participated in. When developing a large system for a car manufacturer, the distributor Dealer, as a .net client, needs to pass the data to the management center, and the data will be used by Oracle's EBS (E-Business System). Because the distributor management system (DMS) adopts the structure of Cramp S, the database is SQL Server, while the EBS database of the automobile manufacturer management center is Oracle. This involves the transfer of data between the two systems.

The implementation architecture is as follows:

First, the data of Dealer is transferred to MSMQ Server through MSMQ, at this time, the data can be inserted into the SQL Server database, and at the same time, the data is transferred to a special file server using FTP. Then use IBM's EAI technology (Enterprise Application Integration, Enterprise Application Itegration) to write the files in the file server periodically, use the interface specification to write to the EAI database server, and finally write to the Oracle database of EBS.

The above architecture is a typical distributed processing architecture, and the core of the technical implementation is MSMQ and EAI. Because we have defined a unified interface specification, after the file is formed through the message queue, the data has nothing to do with the platform, so that the distributor management system under the .net platform can be integrated with the EBS of Oracle to complete the data processing.

The above is all the content of the article "sample Analysis of message processing in the PetShop data access layer". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.