《Microsoft .NET 企業級應用架構設計 (第2版)》 [作者] (意) Dino Esposito (意) Andrea Saltarello[譯者] (中) 李永倫[出版] 人民郵電出版社[版次] 2016年04月 第2版[印次] 2018年05月 第5次 印刷[定價] 69.00元 ...
《Microsoft .NET 企業級應用架構設計 (第2版)》
========== ========== ==========
[作者] (意) Dino Esposito (意) Andrea Saltarello
[譯者] (中) 李永倫
[出版] 人民郵電出版社
[版次] 2016年04月 第2版
[印次] 2018年05月 第5次 印刷
[定價] 69.00元
========== ========== ==========
【第01章】 【今天的架構師和架構】
(P010)
需求經由首席架構師處理之後會交由開發團隊實現。
(P011)
瀑布模型已是明日黃花，你可以將它的死亡歸咎於軟體開發是一種工程學。
軟體開發最流行的敏捷方法學是極限編程 (XP) 。
(P012)
架構師參與開發流程的所有階段，包括需求分析和架構設計、實現、測試、集成以及部署。
架構師的主要職責是 : 確認需求，把系統分解成更小的子系統，識別和評估技術，以及制定規範。
(P013)
架構師確認需求，儘力在設計里採用和滿足它們。
(P014)
架構師需要具備的一個重要特征是語言清晰。
【第02章】 【為成功而設計】
(P020)
雖然 RAD 方案對於以數據為中心的小型簡單應用程式 (如 CRUD 應用程式) 來說可能剛好合適，但事實證明它對於包含大量經常改變的領域規則的大型應用程式來說是一個危險的方案。
(P024)
團隊就是讓在技能上互補的人們互相合作。
(P026)
好的架構師都很清楚，只有寫得好的代碼，對軟體原則和語言特性有很好的瞭解，恰當使用模式和實踐，以及註重可測試性才能解決代碼維護的問題。這使得編碼比產生剛好可以工作的代碼更加昂貴，但比維護和進化剛好可以工作的代碼就廉價得多了。
(P027)
代碼輔助工具不是魔法，它們所做的只是讓你付出更低的代價和更少的努力就可以寫出更好和更乾凈的代碼。
【第03章】 【軟體設計的原則】
(P039)
OOD 的基礎可以總結成以下3點 : 找出相關對象、減少介面對象之間的耦合，以及善用代碼重用。
(P053)
你不選擇設計模式 : 最合適的設計模式通常會在你重構的過程中浮現出來。
【第04章】 【編寫優質軟體】
(P061)
質量好的代碼有一個基本的特點，那就是它必須是可測試的。
(P062)
代碼異味會使代碼變得越來越弱，找出並移除代碼異味是重構的首要目標。
(P072)
領域層是最複雜的部分，也是最受需求波動影響的部分。因此，這個部分的缺陷最多。
(P079)
代碼的質量通過 3 個參數來衡量 : 可測試性、可擴展性和可讀性。
【第05章】 【發現領域架構】
(P083)
DDD 並不適合每個項目，因為它對技能的要求很高，而且啟動成本也很高。
(P085)
關鍵是機會和技能，關鍵是所針對的上下文。
(P094)
所有邏輯層實際上都部署到某個物理層，但不同的邏輯層可能在不同的物理層。
一般而言，我們傾向於把整個應用程式棧部署到單個物理層，如果可能的話。
(P096)
應用程式層是分離表現層和領域層等介面層的絕佳方式。
應用程式層是系統後端的入口點，也是表現層和後端之間的連接點。應用程式層包含的方法幾乎一一對應表現層的用例。
(P097)
應用程式負責實現應用程式的用例。它所做的就是編排任務，並把工作指派給這個棧下麵的其他層。
(P098)
基礎設施層的最突出組件是持久層，它就是一個傳統的數據訪問層，只是還可能覆蓋普通關係型數據存儲之外的一些數據源。持久層知道如何讀取和保存數據。
【第06章】 【表現層】
(P102)
DTO 是一個類，用來攜帶跨越系統的邏輯層和物理層的相關數據。
用戶體驗不只是可視化界面設計，而用戶界面是用戶體驗的一部分，可能仍是最重要的部分。
(P105)
理想狀態下，每個屏幕應該綁到一個視圖模型類，它描述了用來填充視圖的數據。此外，每個屏幕應該綁到一個輸入模型類，它描述了觸發操作時將會離開屏幕的數據。
(P106)
MVVM 尤其適合具有強大雙向數據綁定機制的應用程式場景。
就分層應用程式而言， MVC 、 MVP 和 MVVM 都是表現層的模式。
(P109)
如果 Web API 可以滿足你的需求就用它，否則用 WCF 。
應用程式服務的類包含與用例一一對應的方法。
(P110)
應用程式服務可以訪問這個棧下麵的所有邏輯層和物理層。它可以查詢和更新數據，如果有需要也可以調用外部 Web 服務。
(P113)
給網站添加一個面向設備的層是很有必要的。
(P118)
SPA 首次向伺服器請求只是為了獲取一些初始的 HTML 。一旦用戶界面載入完畢，應用程式也完全初始化了，後續的交互就會通過 HTTP 請求上傳和下載 JSON 數據來進行。
一般而言，如果你打算加入 SPA 大軍，通常的原因是你想充分挖掘客戶端的潛能，獲得一個更好的用戶體驗。
(P120)
SPA 類似於部署到 Web 上的桌面應用程式。
【第07章】 【神秘的業務層】
(P124)
TS 鼓勵你跳過任何面向對象設計，把你的業務組件直接映射到所需的用戶操作上。
(P127)
複雜性是採用領域模型模式的驅動力。
(P130)
在 ASP.NET MVC 應用程式里，任何用戶界面操作最終都會轉化成控制器的類上調用的方法。
(P134)
物理層的數量原則上應該儘可能少。
(P136)
數據傳輸對象專門用來在不同的物理層之間攜帶數據。
作為一個簡單容器，使用 DTO 的原因是它允許你打包多塊數據，在單次往返里傳輸所有數據。
DTO 與生俱來就是可序列化對象。
(P138)
正確地做事的核心理念是效率 : 以優化的方式實現任務，快速且流暢。
做正確的事的核心理念是效益和達成目標。
【第08章】 【領域模型導論】
(P144)
領域層的目標和結構 : 領域模型、模塊和領域服務。
DDD 模塊就像 .NET 命名空間，用來組織類庫項目里的類。
(P145)
值對象只是聚合在一起的數據；實體通常由數據和行為組成。
【第14章】 【持久層】
(P264)
持久層通常會創建成類庫、被領域層 (特別是領域服務) 和應用程式層引用。持久層可以引用任何用於訪問數據的技術，不管是 Entity Framework 或 NHibernate 等 對象 / 關係 映射 (O/RM) 、 ADO.NET 、 NoSQL 資料庫，還是外部數據服務。
(P271)
IQueryable 介面並不負責查詢的實際執行。它所做的只是描述要執行的查詢。執行查詢和構建結果是 LINQ 提供者的任務。
