zoukankan      html  css  js  c++  java
  • Make a "3 layers" framework as the guidance of the "Microsoft application architecture guide" document

    Overview

         When people talk about the architecture of a .net application, there is a term "3 layers" frequently used among them. I recently downloaded the application architecture guidance document from Microsoft website. I found the "3 layers" portion is a big part in the document. That was why people talked about the term so frequently. Many men/women put their insights on the 3 layers topic. I got a little experience in some of the projects I joined, so came up with such pieces of code here and wait for you with great insights to comment it.

         The pieces of code also come with my code generator as official templates. Please find my code generator at : http://www.cnblogs.com/mikelij/archive/2008/12/13/1354268.html,  (Note: the page is in Chinese)

     The code snippet of business entities

     I think the business entity concept comes from the book of Martin Fowler. Martin Fowler made a concept of "anemia object". I think this is something reflecting Martin Fowler's theory. The entity classes do not contain anything but the data structure. Suppose we have a business data called "EMPLOYEE". The entity class of "EMPLOYEE" is looking like the following piece of code:

    The Code of entity class

    The code looks pretty simple. It contains two parts: private members and properties. The properties are getters and setters to expose the private members. The entities classes are used to pass data between other components of the application. It is different from the data transfer object. A typical example of data transfer object is the "DataSet" in .net. The entity class only carries the data related to its business domain. For the example here, the business domain is "EMPLOYEE", then we have the entity class corresponding to the business domain, and the entity class does not contain other business information like "DEPARTMENT". For the case of data transfer object, you can let a DataSet carry a bunch of data, for example both the "EMPLOYEE" and "DEPARTMENT" data, and the relationship between "EMPLOYEE" and "DEPARTMENT", and even more. This tells the entity class from the data transfer object.

    The sample code of Data access layer

    The classes in the Data access layer are consumers of the entity classes. It utilizes the Data helper components to engage with the data connections, authentication, data fetching, etc. The versions of Microsoft enterprise library provide data helper components for application architects. We only apply the version 2.0 of Microsoft enterprise library here. Here is an example of the data access classes: 

    Data access layer Code

    The example data access class incorporated the calls to single sql statement(like insert/delete/update/select) and the calls to stored procedures, and each of the calls can be enrolled into a database transaction. Please take a note on the first parameter of each of the methods. It is an object typed database connection. It can be a database connection object, and also can be a database transaction object. This allows you benefit from leveraging the granularity of a database transaction at the business component layer. Somebody may ask the question: what about the stored procedures, if the stored procedures contain database transaction already, will this helps? My answer: Yes. The transactions in stored procedures will be embeded into a bigger transaction. The bigger transaction is an explicit and manual transaction in the business component layer. You can control which sql query and which stored procedure should be in the manual transaction at the business componet layer, and you can determine the isolation level of the transaction.

         For the case of a manual transaction, you should open database connection and initialize a transaction at the business component layer and pass the transaction object to the data access class.

         By looking at both the classes of data access layer and the class of entity, what idea have you come up? If we merge the data access class and the entity class together into a new class, what does the new class look like? Is it a non-anemia class? Yes. Please let me explain a little bit about why we usually use anemia style classes. When we develop an application with big size, there must be hundreds of tables, and millions rows of data, and the relationship between data must be complicated. We usually try to maintain code files into managable size. What if a table contains 100 columns, the lines of code for fields are several hundred lines of code. That makes the size of a non-anemia class at least should be larger than 200 or 300. And when you try to add the lines of code for sql queries, it should be huge code file. So, we usually divide the data and methods, and then the class for pure data is anemia, and the mothods of a non-anemia class are moved into other code file. Anemia or non anemia is a choice of you. It is up to you. If the size of the application is small, you absolutely can use the non-anemia style.

     The example class of business component

          After finishing the stuff above, we come to the most important part of the application: the business component layer. In this layer, we need to bind the business knowledge and logic into the code. Where does the business knowledge and business logic come from? Apparently it comes from the experts of the business domain. In software development life cycle, we have processes to do requirement engineering. After we collect business and functional requirement, non-functional requirement, we need to consolidate the requirement into the code. Like this:

     

    The Code of business component

     

  • 相关阅读:
    阿里云主机如何重装系统?
    Linux下mysql新建账号及权限设置
    Ahead-of-time compilation(AOT)
    XBOX ONE游戏开发常见问题
    云计算之路-阿里云上:RDS用户的烦恼
    数字证书原理
    《你不常用的c#之二》:略谈GCHandle
    批处理文件指定jre路径启动java桌面应用程序
    关于OAUTH2.0的极品好文
    第一天接触Orchard
  • 原文地址:https://www.cnblogs.com/mikelij/p/1779861.html
Copyright © 2011-2022 走看看