使用 Entity Framework 快速打造關聯式資料庫存取應用程式

Больше похоже на это

部署-WebSite

от 余小章 's

access table

от kuochien lin

Gina自我介紹

от e101007.std e101007.std

香菇栽育銷－old

от 林 光章

使用 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)

用“職責”或“變化原因”來衡量介面或類別設計，也可以套用到方法

三層式架構，如下圖