使用 Entity Framework 快速打造關聯式資料庫存取應用程式
實作
例外
Elmah
捕捉正確的例外
低層模組，不要隨便 throw ex
物件導向的世界，大的很小，小的很大
不是所有的例外都catch的到
應用程式等級的例外
不要太早寫catch
流程問題
邏輯問題
POCO 與一般類別差異之處
IEnumerable vs IQueryable
AutoMapper
ViewModel
Model Mapping
檢查欄位
針對UI設計
$/Internal Training/AutoMapper/AutoMapperUnitTestProject
SQL 裡的Default Value
Metadata
在partial 類別加上，[MetadataType(typeof(PersonMetaData))]
擴充工具所產生出來的類別
若資料欄位為必填，但又有設定Default Value，必須要讓
partial class必須要在同一個命名空間
多人同時開發同一個作業流程，類別名稱重複，使用partial class
使用SQL Profiler觀察Server Control的行為是否符合預期
Linq的延遲執行與立即執行
分層實作方式
Shift+Alt+F10
實作抽像
高層模組依賴抽像
從使用者需求的角度切入
Nuget
THS.ComponentModel
Telerik_UI_for_ASP.NET_AJAX
http://nttp3vs30:8088/nuget
System.Linq.Dynamic
EntityFramework
ORM Solution
LINQ to SQL
NHibernate
Dapper
$/Internal Training/ADO.NET/DapperReadAS400
Entity Framework(Open Source)
Open Source
支援多種關聯性資料庫
Oracle
PostgreSQL
DB2
SQLite
Maria
MySQL
SQL Compact Edtion
SQL Server
為什麼要用ORM?
效能
用事实说话，成熟的ORM性能不是瓶颈，灵活性不是问题：EF5.0、PDF.NET5.0、Dapper原理分析与测试手记
使用 Bulk 改善 Insert/Update/Delete 效能，異動大資料性能比較
查詢大資料性能比較
ORM 缺點
要怎麼提升效能?
徹底瞭解ORM的工作原理
效能提升是需要成本的
在ADO.NET裡面，讀取方式使用 DataReader+Sequential Access 最快
會影響效能的技術
延遲載入 (Lazy Loading)
關聯性物件，不會一次載入，待需要使用時才會動態載入
是優點也是缺點，在適當的情境下使用
SQL Generation，自動產生 SQL 指令
Attribute 宣告自訂對應
Type Converter，列舉型別轉換
Reflection，動態的對應 Property 和 Field
效能損耗
ORM 優點
Connection Pool 自我管理
自動緩存(cache)查詢，減少網路流量
Lazy Loading，消極式載入，有用到才會載入，節省流量
更容易處理關聯物件Relation
自動處理資料庫注入攻擊(SQL Injection)
自動產生 SQL 語法，程式設計師不需要瞭解各個不同的SQL語法
對架構而言已經面對物件，所以當遇到資料庫轉移或切換，不需要變更原有程式
動態將資料表轉換成物件(class)，消除魔術字串，依賴IDE的IntelliSense，降低除錯成本
降低對資料庫的學習成本，更專注在商業、業務邏輯
什麼是ORM
由『物件資料』到『關聯資料庫的存儲』對映的技術，將資料庫操作用物件導向的形式來呈現
3 Layer
3 Layer 缺點
分層無法封裝所有的東西，例如因應需求要在前端介面增加 輸入欄位，必須要在表現層、商業邏輯層、資料存取層都做 相對應的修改
不合理的分層使得不同層次的程式碼耦合在一起，相依性增加，使得程式越來越難以隨著需求變更而進行相應調整
不合理的分層將會導致軟體開發品質下降
過多的分層會影響效能
3 Layer 優點
各層之間具有一定的"獨立性"，維持之間溝通的介面不變，各層可以根據具體問題各自實作，而不需要其他層也必須做出相應調整
合理的分層有助於分工開發與維護，哪一層壞了就改哪一層
可提高抽換性、可維護性、可測試性
有利於標準化
可以將各層次間的相依性減到最低
以替換某一層的具體實現，只要前後提供的服務相同即可
3 Layer 職責
Repository/Data Access/Persistence/PO/DAO
資料倉儲
Model
各Layer之間的資料模型定義
Business/BO
商業邏輯
Control
作業流程控制器，由UI接收資料，決定資料該往BO或是DAO處理
UI
使用者操作介面
物件導向六大原則：SOLID
D：依賴反轉原則，抽象化。(Dependency Inversion Principle)
細節應依賴抽象
抽象不應依賴細節
高層模組不應依賴低層模組，兩者都應依賴其抽象
I：介面隔離原則，介面要特定目的、易懂、可再用性高。(Interface Segregation Principle)
客戶端不應該依賴他不需要的介面，類別間的依賴關係應該建立在最小的介面上。
L：最少知識原則，（Least Knowledge Principle, LKP），又稱狄米特法則（Law of Demeter, LoD）
一個物件應對其他物件有最少的了解。通俗來說就是我只要知道你提供這麼多public方法，其他我都一概不關心。
L：里氏替換原則，類別間的相容性。(Liskov’s Substitution Principle)
父類別能出現的地方，子類別就可以出現，而且替換成子類別不會造成錯誤或異常。
O：開放封閉原則，開放擴充、封閉修改。(Open-Closed Principle,OCP)
應該透過擴展來實做變化，而不是修改已有的程式碼來實作變化
S：單一職責原則，單一類別單一責任、低耦合 (Single Responsibility Principle,SRP)
用“職責”或“變化原因”來衡量介面或類別設計，也可以套用到方法
三層式架構，如下圖
