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.

Xcode8 及iOS10适配问题汇总

1.Notification(通知)自从Notification被引入之后,苹果就不断的更新优化,但这些更新优化只是小打小闹,直至现在iOS 10开始真正的进行大改重构,这让开发者也体会到UserNo...
  • c386890506
  • c386890506
  • 2016年09月21日 07:34
  • 2624

iOS10软件崩溃 Xcode8崩溃 打印/字体等问题汇总 韩俊强的博客

iOS10 Xcode8问题汇总 每日更新关注:http://weibo.com/hanjunqiang 新浪微博!iOS开发者交流QQ群: 446310206...
  • qq_31810357
  • qq_31810357
  • 2016年09月18日 08:43
  • 14793

Xcode8以及iOS10问题记录

Xcode8以及iOS10问题记录:1.解决工程中输出无关日志,2.注释快捷键⌘+/失效,3.对于插件无法使用,4.iOS10隐私权限问题,5.label中的文字显示不全,6.Notification...
  • FloatingDreamSH
  • FloatingDreamSH
  • 2016年09月21日 10:55
  • 7774

Recent Evolution of Zero Data Loss Guarantee in Spark Streaming With Kafka

When properly deployed, Spark Streaming 1.2 provides zero data loss guarantee.
  • jiweiwong
  • jiweiwong
  • 2016年03月30日 09:18
  • 231

The Evolution of Distributed Programming in R

By Paulin Shek Both R and distributed programming rank highly on my list of “good things”, so ima...
  • u014032673
  • u014032673
  • 2016年01月08日 15:26
  • 364

《Description of CWnd derived MFC objects and multithreaded applications in Visual C++》译文

原文地址: http://support.microsoft.com/default.aspx?scid=kb;en-us;147578 译文: 《Visual C++ MFC CWnd及其子类...
  • kniferlv0
  • kniferlv0
  • 2012年09月19日 00:34
  • 519

The role of space in social groups Analysis and technological applications

  • 2015年06月03日 22:02
  • 2.61MB
  • 下载

Handbook of Geometric Computing Applications In Pattern Recognition part1

  • 2008年07月09日 10:29
  • 9MB
  • 下载

Applications_of_connectivity_graph_processes_in_networked_sensing_and_control

  • 2012年08月28日 11:11
  • 303KB
  • 下载

Role of Spark in transforming eBay’s Enterprise Data Platform

  • 2016年02月26日 09:59
  • 9.8MB
  • 下载
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:The Evolution of Layers in Enterprise Applications
举报原因:
原因补充:

(最多只允许输入30个字)