Realize database transactions with Microsoft.net
Summary: Learn about how .NET's PET SHOP 2 Enterprise version helps companies solve the actual business problem, Net PET SHOP
Verify how the best enterprise system is developed using the .NET framework and Visual Studio.net. As Sun's JavaTM Pet Store J2EETM BluePrint Application, it is also an optimal system implementation.
Introduction
The .NET Pet Store Program is developed in November 2001, which describes how .NET developers use the Best system for development .NET framework and Visual Studio.net. The discussion about pet stores and the original J2EE pet store involves some characteristics of enterprise-level systems, such as reliability and scalability. For a system to deploy into an enterprise level, you must consider its security, reliability, scalability, manageability, and work with the existing system and data. The cost advantage, performance and development efficiency of the previous version of the pet store system still exists on the .NET platform. This article describes the discussions of the pet store to in-depth by describing other enterprise needs of .NET support.
Many companies have distributed data in different systems, such as inventory data in an inventory control system, but customer data data is in their CRM system. Our system needs to handle data in these different databases, and ensure that data changes are correct in these systems. To achieve these requirements, we need transactions across the database.
Pet Shop Enterprise Version is to showcase the technology of those enterprise-level systems in order to showcase .Net platform. It provides a reliable, scalable system in processing data storage in the real world. Pet Store Enterprise Version Processes some cases, such as customer data exists in a client database system on a server, and customer order data exists in a different database system on a physical different server, there are many The agency is a general phenomenon.
To ensure that customer data and customer order data are always correct, there is a distributed system that contains the two data sources. This article discusses different mechanisms in the .NET enterprise system, gives example code for each mechanism, and discusses some best practices. The code in this article is written in C #, but all methods and techniques apply to VB.NET.
Distributed transactions across multiple databases discussed herein have long been proven to have excellent performance and scalability for one system. The performance of several transaction mechanisms on the .NET platform is also tested here, detailed listings and the results of their results. From these results, we can clearly see that .NET provides excellent enterprise-class transaction support from functional and performance.
This article also includes some presentation of a pet store, its initial architecture and implementation, and some changes to it in order to support enterprise-class features. Different transactions and their test performance results are also discussed in detail.
See How Sun Microsystems' Java Pet Store J2EE BluePrint Application Was Implement Using Microsoft .NET.
Hypothesis
Suppose an e-commerce company that can order pets online, when you enter the system, you can browse, query the various types of pets from dogs to reptiles.
A typical pet store system includes:
l Homepage - When you open the page after the system is loaded.
l Category Browse - There are five categories on the top, and there are several products below each category.
l Products - When a product inside the system is selected, the properties of the product are displayed, typical as public or mother.
l Product Details - Detailed description of each product attribute, such as photos, prices and stock quantities.
l Shopping Cart - Allows customers to maintain a shopping cart (increas, delete, update quantity).
l Check - read only a shopping cart information.
l Login Orientation - When the user selects to continue on the checkpoint, if he has not logged in, it will be directed to the login page. l Verify Login - When logging in is verified, it will be transferred to the credit card information and the order address information page.
l Confirm that the order - orders and customer address information are displayed waiting for confirmation.
l Submit the order - the last step, here the order is submitted to the database.
An example of a pet store is as shown:
Figure 1: .NET Pet Shop
. The overall logical architecture of the NET pet store is as shown:
Figure 2: .NET Pet Store Logic Architecture
There are three logic layers: indicating layers, intermediate layers, data layers, which can make different feature distributed systems clear deployment, and logical layers are installed into a .NET assembly (implementation with C # class libraries), for the database Access is to handle all interactions with SQL Server Managed Provider, with the stored procedure to access data, this system utilizes the .NET implements a full logical three-layer architecture, which shows the most on the .NET platform Good practice.
Figure 3: Physical deployment diagram of .NET pet store system
Programming architecture
Figure 4 is a detailed diagram for expressing our design, we can see the implementation and interaction details of each layer of the pet store
Figure 4: Architecture envision
database
The database has the following table
Table Name
Explanation
Account
Basic customer information
Bannerdata
Storage ad and slogan information
Category
Category information (such as fish, dogs, cats, etc.).
Inventory
Product inventory information
Item
Each product details
LineItem
Settlement
ORDERS
The order under the customer, a single order contains one or more set order
ORDERSTATUS
Order status
PRODUCT
Product catalog, each product contains one or more attributes, typical properties such as publicmother.
Profile
Customized information
Signon
Customer login information
Supplier
Supplier information
Table 1: Database Table Name
.NET pet store transaction implementation
The database transaction is used in the stored procedure of the Order class in the original .NET Poke store, this call involves four tables of data and needs to define the ACID attribute. Because if a single order is created, the inventory data needs to be adjusted. The stored procedure uses an XML document to do parameters, inserts order data, fixed order, inserts set status data, updating the inventory data involved in the order involved in the order, our goal is to become a distributed database architecture from a single database architecture, that is Customers, product and inventory data exist in a database, ordered in another database. In order to achieve this goal, we need to move to a business service architecture, which is the only mechanism that controls distributed transactions and provides two phases. In order to transfer to enterprise service level, we need to investigate the impact of several situations:
l Incorporate the enterprise service class, but use database transactions /ado.net transactions
l Introducing Enterprise Service Class Library, using it to control transactions
l Introducing the Enterprise Service Class library, using it to control distributed transactions
In order to achieve distributed transactions, we need to modify the Adorder method and database interaction, in a single database situation, we use a stored procedure; for distributed, we need to become two stored procedures, one for each database, we Recognizing that the original stored procedure is connected between the last table, now these forms are in different databases, so we best place these implementations in the intermediate layer and dynamically generate SQL statements.
In order to display the influence of the introduction of the enterprise service class for each component, we have designed several versions of the .NET Pet Shop: L as the foundation with the original .NET Pets V1.5
l Use an ADO.NET transaction .NET Pet Store
l Using the Enterprise Service Class Library and ADO.NET Transactions (the transaction property of the enterprise service is set to "not support")
l Using business services (transaction attributes are set to "need", ADO.NET is removed)
l Use business services to handle distributed transactions
Database design in distributed case
Figure 5: Pet Store Database Model
Figure 6: Set Database Model
.NET transaction mechanism
.NET developers can use four mechanisms:
l Database transaction
l ADO.NET transaction
l asp.net transaction
l Enterprise service level transaction
Each mechanism has its own advantages and disadvantages: performance, code, deployment settings. Many developers are familiar with the database's transactions. In this case, the intermediate layer calls the database stored procedure, starting a transaction during the stored procedure, if each statement is executed, then submit, if there is an error, it will roll back .
If your transaction needs a few calls, for example, you need to insert multiple sets into a table, but don't want to use an XML document or pass a long string, you need to be parsed in the stored procedure, you can Use the ADO.NET transaction mechanism. ADO.NET transactions allow you to create a transaction context on the current connection, run multiple calls to the database, in the end, or submit or roll back.
The ASP.NET transaction is working on the page layer of the web application, as long as you add a "Transaction =" Required "in the page properties, this event handles in the page are part of the entire transaction, any processing error , All processing will roll back.
Enterprise Services Components implements transactions through the Explorer and Distributed Transaction Controller (DTC), when ASP.NET, a database call, or other resource involved in transactions, the entire transaction will be rolled back, Enterprise services are based on COM technology to handle transactions, and developers who are familiar with COM should understand business services.
It is possible to be mentioned that there may be mutually exclusive, if you mix the database transaction and enterprise service transaction, you will get a repetition, you are in the business The service may be submitted to a transaction that has been submitted in a database transaction, so that there is no transaction context to make a submission action. The same problem is as submitted in a database transaction, but in the enterprise service, it rolls back in the system.
