《Microsoft .NET 企業級應用架構設計 (第2版)》 - 學習筆記

**《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 提供者的任務。**