BY ROCKY LHOTKA
2004.12.15
http://www.theserverside.net/articles/showarticle.tss?id=fallaacyDatalayer
It is well known that a typical application has interface layers, business layers, and data layers. In most of my works, I am using 4 layers: interface, business, data access, data storage layer (UI, Business, Data Access and Data Storage). In this case, the data storage layer is indeed with traditional 3 The same in the layer structure.
However, here I want to challenge and question the concept of the data layer. In the past few months, in discussing services and distributed object-oriented architectures, I am increasingly convinced that the three concepts of physical data layer, Data Layer and Data Storage Layer. There is a fundamental defect and confusion.
Note that in this article, I use the Layer to describe the level on the logical concept, and describe the physical separation hierarchy with Tier. That is, it is clear that a typical logical data layer Layer is also a physical data layer because most of the logical data layers are driven by SQL Server, Oracle, or other database services.
Service-oriented design gives us such a point: any components used by more than one component (or said multiple clients) should be a service. The service is a superior software reuse unit, which provides a contractual interface, and the client can interact with the service through this interface.
More importantly, a service defines a trust boundary. That is, service protects yourself from illegal clients. This is a service-oriented definition element, and it is a key point: this service can be very secure to serve different clients because it trusts all clients (My Website Note: Original THE BENEFIT IS THAT A Service CAN Safely The Service Many Disparate Clients Because It trusts none of them is wrong and should be all of them.). Services To confirm that all clients have the same behavior, and any data sent to the service should be validate based on the service rule.
The focus of my debate is that the traditional data layer is an ideal candidate for services.
Consider all layers in a typical application: user or other person, the technology, interface logic, business logic, data access logic, data source. We can make this structure as a stack, from the user to the data source, application logic is like the intermediate sandwich.
However, we need to carefully consider which parts we really control it. It is clear that we cannot control users or other (software) consumers - they are entities other than system-wide, or known as external entities.
We can control the performance of the program to a large extent, which is to control user interfaces and business logic layers. After all, we write these code in the application. The data access layer is also the same, he is just some code to interact with the data source.
Now let's take a look at the data source itself. In a typical application scene, we control the data source? Oh, in many cases, we answer "no". In many cases, the data source is a database, a set of relational tables, and in reality, other applications or people have often accessing those identical tables, which is not within our control, so we cannot guarantee They do not use illegal operational logic, and the correct logical rules and usage are defined within our system.
This is not to say that data violates the consistency rules and operations of the database, but those rules and operations are rarely matched to our application rules, at least not exactly. This means that there is often no match between business logic and database built rules. It is said that I can't control any end of "spectral", and the user and database seem to be outside our control. In short, I think the data layer is an external entity.
Microsoft's PAT Helland talked to the service should be a homemade entity. He contains business behavior and logic, and he also pays special attention to each service has its data source. Is it that a given service (program) has a proprietary control and access data source? I agree with the content he talks, but this is rarely applied and appeared in the actual corporate organization.
The reality is that a service (program) is shared with other service sharing data sources, and other services (programs) have access to the data source. Others (administrators, superusers, etc.) often directly access the database and bypass the application logic.
I think there must be trust between a separate application, I have written on my blog on trust border and any time if we have to cross the trust boundary, we must consider we have two independent applications. This is because an application is defined within its own trust boundary.
I realized that I am defining a word application in a special way, and that is intentional. Many about service-oriented discussions, even discussions about the N-layer architecture are discussed in semantic or proprietary noun. We must define a terminology about discussion.
So, an application Application is a group containing code, objects, components, services, layers (Layers or tiers) included in a certain trust boundary, and they trust each other without having to repeat business logic (verification, calculation, operation, etc.). Authorization) because they fully trust each other. If the data is verified or operated at a layer, then all other layers think it is correct.
The views stated on the upper side think that the constructing the implementation of the application is good, at least logically feel so. That is, the external entity (user or other application) cannot interact directly with the code, object, component, service, layer, unless the official external interface of the application (user interface / performance layer or service interface) ).
If you agree to the above definitions and conclusions, it is clear that the data source can only be a layer as a data source as an application proprietary. If the data source is not proprietary, other applications and users can interact directly without interacting with our application performance layer / interface layer. In this case (this is usually, not special case), the data source should not be a layer of the application, because he exists outside the trust boundary, must be considered as an external entity (just like the user or Other applications).
What does this mean from the actual project angle?
Oh, he means that our app cannot trust the data source, but, more deeper thinks, which means that we need fundamental remember the architecture of the application (or service).
What is the user? From the perspective of an application, a user is a source or event trigger source. In the object-oriented world, users are easily described as another object in our object model, and in the service-oriented world, users are only described as another service with us.
In fact, we can further think that ADO.NET, XML, Web Services, HTML, and GUI are only external interface technology. What I recommend here is that there is no thing like a layer / UI layer, at least without substantial differences from the data access layer (or service agent layer), as shown below:
In the figure, the brick type represents the application trust boundary, our business logic, and any other trusted objects, components, and services are included within the trust boundary box. In addition to the boundary of the trust, there is end user, data source, external service and proxy system. Our application must interact with them must pass the trust boundary, that is to say they are not trusted by our app. I found that it is especially compulsive in consideration of distributed object-oriented architectures. I have discussed a lot of applications and services, and should be created in an object-oriented way, how can I treat us to see the world to see the world? Is there a difference between users, data sources, services, and other uncontrollable objects? There is no foundation, each is just an external entity we need to interact. In different cases we interact with them through special interface software, it is possible to be ADO.NET, Windows user interface, or XML parser.
If the application is used as the center of any architecture, we can standardize our way to think about external entities. Data from users, events, more or less more valuable than from data sources or external services. Our business logic must verify, calculate, and operate data without the source of data.
This means that the layer of the typical application will be simpler:
l external interface
l The internal business logic is inside.
External interfaces can be manifested in a variety of forms, including:
l Data Access Layer (like ADO.NET)
l Serving agent (such as calling the Web Service class)
l HTML interface (interact with network users)
l GUI interface (interact with Windows users)
In each case, the external interface is responsible for sending and receiving data, as well as motivation and response events. More abstract, external interfaces send and receive messages, allowing interactions with external and unin-reliable entities.
In short, most of the data sources are proprietary, they are shared by many applications, so from service-oriented perspectives, the data source can be considered an ideal candidate service provider. The same is true for other shared external entities, like data sources, users, and other services. So I think we need to challenge and suspect the traditional 3-story architecture application model, thus considering a new architecture model!
About the Author:
Rockford Lhotka wrote a lot of books, "Expert One-ONE Visual Basic .Net Business Objects", "Expert C # Business Objects, and so on. He is a Microsoft Software Legend, Regional Director, MVP and INETA speaker He is a columnist for MSDN Online and contributing author for Visual Studio Magazine, and he regularly presents at major conferences around the world -. Including Microsoft PDC, Tech Ed, VS Live And vs Connections.
