系統架構設計師要學習的內容很多，爲了方便大家，下面整理了一些關於系統架構設計師複習資料，希望對大家有所幫助!
IOC技術應用
1) 我們看看我們常用的配置文件應用(對象級的反轉)
2) 在設計模式中，我們已經習慣一種思維編程方式： 接口驅動
3) 其實就是javabean的思想，注入和發射思想
17.1.1 IOC的技術結構(面向技術經理和開發人員)
1) XML設置
2) 配置性能和對象還原
3) 反射機制應用方式反射的代價
4) 可配性(替代很多設計模式)
5) 減少硬性編碼
DriverManagerDataSource
BasicDataSource
JndiObjectFactoryBean
系統架構師對技術的把握
1)新技術的更新，關注點和深度不同(技術風險)
2)對公司技術實力和技術方向的正確把握
3)不追求最新、不能把架構風險輕易帶入系統。注意前期對新技術的測試。
4)設計模式解決了設計可擴展性問題，並不等於解決了性能問題，性能問題要進行瓶頸測試，並對設計和性能的矛盾進行權衡。非功能性問題(併發、網絡、事務、操作系統、安全、穩定性、性能)
5)設計原則
系統架構師UML如何賦予實施，用到實處
1)要讓UML指引項目的開發而不是一個裝飾品.如何同步你的設計文檔和需求文檔、類變化
2)以CA用例爲例
3)作爲交流的一種工具，不需要繁雜的UML圖。
4)各種UML圖的實際設計應用
系統架構師如何設計和使用ORM(具體由技術經理督促實施)
1)JDBC應用問題
2)持久化開發效率和應用效率的矛盾平衡
17系統架構師的框架另一個選擇Spring(輕量級的選擇)
1)時代的產物
2)集大成者，一個開發的骨架
使用分頁和惰性加載
在大多數情況下，您應該僅在需要時檢索或顯示數據。如果您的應用程序需要檢索和顯示大量信息，則 您應該考慮將數據分解到多個頁面中，並且一次顯示一頁數據。這可以使用戶界面具有更高的性能，因爲它無須顯示大量數據。此外，這可以提高應用程序的可用 性，因爲用戶不會同時面對大量數據，並且可以更加容易地導航以查找他或她需要的確切數據。例如，如果您的應用程序顯示來自大型產品目錄的產 品數據，則您可以按照字母順序顯示這些項，並且將所有以“A”開頭的產品顯示在一個頁面上，將所有以“B”開頭的產品顯示在下一個頁面上。然後，您可以讓 用戶直接導航到適當的頁面，以便他或她無須瀏覽所有頁面就可以獲得他或她需要的數據。以這種方式將數據分頁還使您可以根據需要獲取後臺的數據。例如，您可能只需要獲取第一頁信息以便顯示並且讓用戶與其進行交互。然後，您可以獲取後臺中的、已經準備好供用戶使用的下一頁數據。該技術在與數據緩存技術結合使用時可能特別有效。您 還可以通過使用惰性加載技術來提高智能客戶端應用程序的'性能。您無須立即加載可能在將來某個時刻需要的數據或資源，而是可以根據需要加載它們。您可以在構 建大型列表或樹結構時使用惰性加載來提高用戶界面的性能。在此情況下，您可以在用戶需要看到數據時(例如，在用戶展開樹節點時)加載它。
考慮應用程序操作環境
對應用程序的操作環境進行評估是很重要的，因爲這可能對應用程序施加必須在您制定的性能目標中予以反映的約束。位於網絡上的服務可能對您的應用程序施加性能約束。例如，您可能需要與您無法控制的 Web 服務進行交互。在這種情況下，需要確定該服務的性能，並且確定這是否將對客戶端應用程序的性能產生影響。您 還應該確定任何相關服務和組件的性能如何隨着時間的變化而變化。某些系統會經受相當穩定的使用，而其他系統則會在一天或一週的特定時間經受變動極大的使 用。這些區別可能在關鍵時間對應用程序的性能造成不利影響。例如，提供應用程序部署和更新服務的服務可能會在星期一早上 9 點緩慢響應，因爲所有用戶都在此時升級到應用程序的最新版本。另外，還需要準確地對所有相關係統和組件的性能進行建模，以便可以在嚴格模擬應用程序的實際部署環境的環境中測試您的應用程序。對於每個系統，您都應該確定性能概況以及最低、平均和最高性能特徵。然後，您可以在定義應用程序的性能要求時根據需要使用該數據。您還應該仔細考慮用於運行應用程序的硬件。您將需要確定在處理器、內存、圖形功能等方面的目標硬件配置，或者至少確定一個如果得不到滿足則無法保證性能的最低配置。通常，應用程序的業務操作環境將規定一些更爲苛刻的性能要求。例如，執行實時股票交易的應用程序將需要執行這些交易並及時顯示所有相關數據。