The Evolution of Layers in Enterprise Applications
2004-08-06 10:08
513 查看
The Evolution of Layers in Enterprise ApplicationsAlthough I'm too young to have done any work in the early days of batch systems, I don't sense that people thought much of layers in those days. You wrote a program that manipulated some form of files (ISAM, VSAM, etc.), and that was your application. No layers need apply.The notion of layers became more apparent in the '90s with the rise of client杝erver systems. These were two-layer systems: The client held the user interface and other application code, and the server was usually a relational database. Common client tools were VB, Powerbuilder, and Delphi. These made it particularly easy to build data-intensive applications, as they had UI widgets that were aware of SQL. Thus you could build a screen by dragging controls onto a design area and then using property sheets to connect the controls to the database. If the application was all about the display and simple update of relational data, then these client杝erver systems worked very well. The problem came with domain logic: business rules, validations, calculations, and the like. Usually people would write these on the client, but this was awkward and usually done by embedding the logic directly into the UI screens. As the domain logic got more complex, this code became very difficult to work with. Furthermore, embedding logic in screens made it easy to duplicate code, which meant that simple changes resulted in hunting down similar code in many screens. An alternative was to put the domain logic in the database as stored procedures. However, stored procedures gave limited structuring mechanisms, which again led to awkward code. Also, many people liked relational databases because SQL was a standard that would allow them to change their database vendor. Despite the fact that few people actually did this, many liked having the option to change vendors without too high a porting cost. Because they are all proprietary, stored procedures removed that option. At the same time that client杝erver was gaining popularity, the object-oriented world was rising. The object community had an answer to the problem of domain logic: Move to a three-layer system. In this approach you have a presentation layer for your UI, a domain layer for your domain logic, and a data source. This way you could move all of that intricate domain logic out of the UI and put it into a layer where you could structure it properly with objects. Despite this, the object bandwagon made little headway. The truth was that many systems were simple, or at least started that way. And although the three-layer approach had many benefits, the tooling for client杝erver was compelling if your problem was simple. The client杝erver tools also were difficult, or even impossible, to use in a three-layer configuration. I think the seismic shock here was the rise of the Web. Suddenly people wanted to deploy client杝erver applications with a Web browser. However, if all your business logic was buried in a rich client, then all your business logic needed to be redone to have a Web interface. A well-designed three-layer system could just add a new presentation layer and be done with it. Furthermore, with Java we saw an unashamedly object-oriented language hit the mainstream. The tools that appeared to build Web pages were much less tied to SQL and thus more amenable to a third layer. When people discuss layering, there's often some confusion over the terms layer and tier. Often the two are used as synonyms, but most people see tier as implying a physical separation. Client杝erver systems are often described as two-tier systems, and the separation is physical: The client is a desktop and the server is a server. I use layer to stress that you don't have to run the layers on different machines. A distinct layer of domain logic often runs on either a desktop or the database server. In this situation you have two nodes but three distinct layers. With a local database I can run all three layers on a single laptop, but there will still be three distinct layers. |
相关文章推荐
- The Best of Both Worlds: Integrating JSF with Struts in Your J2EE Applications
- How to get and set the drawing order of layers in globe(获取并设置Globe图层的叠加次序:)
- The Best of Both Worlds: Integrating JSF with Struts in Your J2EE Applications
- The Role of Forcing in Cell Morphology and Evolution within Midlatitude Squall Lines-2005
- Software Rules: How the Next Generation of Enterprise Applications Will Increase Strategic Effective
- The Best of Both Worlds: Integrating JSF with Struts in Your J2EE Applications
- The evolution of self-defense technologies in malware
- The Evolution of the web and web applications
- The evolution of self-defense technologies in malware
- What are the layers of data description in R/3?
- The Evolution of Distributed Programming in R
- 读《The web of topics: discovering th topology of topic evolution in a corpus》笔记
- Hack the Stack: Using Snort and Ethereal to Master the 8 Layers of an Insecure Network [ILLUSTRATED]
- This version of the rendering library is more recent than your version of ADT plug-in. Please update ADT plug-in
- Special Applications of Iron Ore in Mineral Industry
- hdu 5095 Linearization of the kernel functions in SVM 坑多的水题 细节
- Agile Project Management: How to Succeed in the Face of Changing Project Requirements
- The first step of my life in the EC field
- 70-565 Pro: Designing and Developing Enterprise Applications Using the Microsoft .NET Framework 3.5 考试感言