The Evolution of Layers in Enterprise Applications

原创 2004年08月06日 10:08:00

The Evolution of Layers in Enterprise Applications

Although 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.

Installation of SUSE Linux Enterprise Server 12

Installation of SUSE Linux Enterprise Server 12 by Editor | Published: April 8, 2015 | Last Updat...
  • Real_Myth
  • Real_Myth
  • 2016年07月12日 12:42
  • 1811

The Evolution of the web and web applications

keywords: web 万维网 medium 媒体 sharing 分享 desktop 台式 桌面 desktop computer 台式计算机 notebook computer...
  • qq_29854443
  • qq_29854443
  • 2017年05月29日 22:58
  • 99

信用评分书目(Credit Scoring: Reading List)

  • gqm1982
  • gqm1982
  • 2010年09月03日 11:16
  • 2196

什么是LTE(Long Term Evolution)

LTE(Long Term Evolution,长期演进)是由 3GPP(The 3rd Generation Partnership Project,第三代合作伙伴计划)组织制定的 UMTS(Uni...
  • LRachelChao
  • LRachelChao
  • 2017年04月19日 21:52
  • 251

Evolution 使用QQ邮箱

CentOs7 中使用QQ邮箱 1.登录qq想象,开启
  • gzuimis
  • gzuimis
  • 2014年11月19日 21:23
  • 987


转自: 虽然在开源的世界里有很多优秀的电子邮件客户端,可是笔者仍然认为Evolution是不错的...
  • segments
  • segments
  • 2011年11月18日 14:56
  • 5409

[阅读]企业级应用(Enterprise Applications)

1、企业级应用的概念  企业级应用(Enterprise Applications),是一个企业范围内所使用的、基于计算机的稳定的、安全的和高效的分布式信息管理系统。2、企业级应用(1)分层:持久层(...
  • Starsiday
  • Starsiday
  • 2006年09月11日 19:01
  • 801

Developing .NET Enterprise Applications

版权声明:原创作品,允许转载,转载时请务必以超链接形式标明文章原始出版、作者信息和本声明。否则将追究法律责任。 - topmvpDevelopin...
  • topmvp
  • topmvp
  • 2008年12月06日 18:50
  • 248


在用evolution代收163邮箱的邮件时候,要在登录的网页中的163邮箱里的“设置”中的  “POP3/SMTP/IMAP” 选项把相应的协议勾上如图:一般接收是用POP3服务; 0: ...
  • VictorLee0321
  • VictorLee0321
  • 2015年04月05日 01:26
  • 2780


  • zh9406
  • zh9406
  • 2014年12月23日 19:46
  • 371
您举报文章:The Evolution of Layers in Enterprise Applications