本書的大部分內容我都是討論邏輯層：將系統劃分為不同的部分，以減少系統不同部分之間的耦合。即使所有的層都執行在同一臺物理機器上，它們之間的分離也是有用的。但系統的不同物理架構所處的位置也有所不同。
對於大多數is應用程式，決定就是是否在一台客戶端、桌面機器，伺服器上執行處理過程。
最簡單的情況就是在伺服器執行所有的一切。通過運用使用web瀏覽器的html前端是實現此方案的乙個好方法。在伺服器上執行一切的最大的好處就是所有東西都是容易更新和修正的，因為它們在都處在有限的地點。你不必要擔心在多個桌面機上佈署，並使它們與伺服器同步。你不必要擔心與其它桌面軟體的相容性。
對於贊同在客戶端執行邏輯的一般爭論就是響應速度或斷開連線操作。在伺服器上執行的任何邏輯需要伺服器對使用者的響應做出一次往返。如果使用者希望立即看到結果，那麼往返就成為了障礙。它也需要乙個網路連線來進行操作。
資料來源幾乎始終只在伺服器上執行。例外就是你可能希望將伺服器功能複製到一台合適的強大的客戶機上。通常出現在你希望進行離線操作的情況下。在這種情況下，對於離線客戶端上修改的資料需要與伺服器進行同步。
對於在何處執行顯示的決定很大程度上依賴於你想要的使用者介面。執行富客戶端多數意味著在客戶端執行顯示。執行web介面多數意味著在伺服器上執行。例外就是在桌面執行web伺服器的客戶端軟體的運程操作（例如，unix世界中的x伺服器），但這種情況很少見。
人們希望富客戶端表現的主要原因是因為一些任務對於使用者來說在太複雜了，並希望擁有乙個web gui可以提供的更多的可用的應用程式。然而，人們正在使得web前端更為可用，這減少了對於富客戶端的要求。當我寫下這篇文章的時候，我更傾向於使用web表現，如果可以的話。
現在只剩下業務邏輯了。你可以在伺服器上或客戶端上執行所有的業務邏輯或分割它們。在伺服器執行所有的邏輯是便於維護的最簡單的方式。對於將它轉移到客戶端的需要或者是響應速度或者是離線使用。
如果你必須在客戶端執行某些邏輯，你可以考慮在那兒執行所有的邏輯－使用這種方式，它們至少都在同乙個地方。在客戶端執行web伺服器對於改善響應速度並沒有太大的提高，雖然這是處理離線操作的一種方式。在這種情況下，你仍然可以在不同的模組中保持業務邏輯和表現的分離，實際上你可以使用transaction script或domain model達到這個目的。將所有的業務邏輯放到客戶端的問題是這種方式需要你做更多的事以進行更新和維護。
在桌面和伺服器間分割業務邏輯聽起來是最壞的方案，因為使用這種方式，你不知道邏輯片段到底在什麼地方。使用這種方式的主要原因是因為你有一些小的業務邏輯需要在客戶端執行。這裡有乙個小技巧是將這個邏輯片段封閉入乙個自包含的模組中，這個模組不依賴於系統的其它任何部分。這樣，你就可以在客戶端或伺服器的任何一端執行這相模組。一旦，你選擇了你的處理節點，你就應該將所有**放入乙個過程的乙個結點中。不要試圖將層分離放入不同的過程中，除非你必須這樣做。因為，如果這樣做會導致效能的下降和當你必須加入例如remote facade和data transfer ojbect的複雜性。
選擇與執行
出差回來，打算這個週末整理一下過去自己所有網路收藏你內容，回頭看去才發現裡面有很多不錯的內容，有方 層面改變思維觀念你，這周一些具體操作步驟的，經常回顧整理自己的收藏也是一種不錯的進步途徑。摘錄剛看到裡面你不錯的兩段話。人的選擇有很多，就像錢鍾書 圍城 裡面說的一樣，城裡面的人想出來，城外面的人想進...
PostgreSQL在何處處理 sql查詢之二十九
接前面，繼續分析 chooseportalstrategy chooseportalstrategy select portal execution strategy given the intended statement list.the list elements can be querys,...
PostgreSQL在何處處理 sql查詢之三十
接前面，繼續分析 portalstrategy chooseportalstrategy list stmts else if isa stmt,plannedstmt else portal one returning has to allow auxiliary queries added by...