共用方式為

移轉考量 (Entity Framework)

  • 發行項

ADO.NET Entity Framework 可以為現有應用程式提供幾項優勢，其中一項最重要的優勢就是使用 實體資料模型 (EDM) 將應用程式所使用的資料結構從資料來源中的結構描述分隔。這樣能方便您以後對儲存體模型或資料來源本身進行變更，而不必對應用程式進行補償變更。如需 實體架構 使用優勢的詳細資訊，請參閱 Entity Framework 簡介。

若要善用 實體架構 的優勢，您可以將現有應用程式移轉至 實體架構。有些工作通用於所有移轉的應用程式。這些通用工作包括將應用程式升級為使用 .NET Framework 3.5 版 Service Pack 1 (SP1)、定義 EDM，以及設定 Entity Framework。在將應用程式移轉至 實體架構 的時候，有其他的適用考量。這些考量取決於要移轉的應用程式類型以及應用程式的特定功能。本主題所提供的資訊有助於您選擇在升級現有應用程式時要使用的最佳方式。

一般移轉考量

下列考量適用於將任何應用程式移轉至 實體架構 的情況：

  • 任何使用 .NET Framework 3.5 的應用程式都可以被移轉至 Entity Framework，只要應用程式使用之資料來源的資料提供者 (Data Provider) 支援 Entity Framework 即可。

  • Entity Framework 可能無法支援資料來源提供者的所有功能，即使那個提供者支援 Entity Framework 也一樣。

  • 針對大型或複雜應用程式，您不必一次將整個應用程式移轉至 Entity Framework，但是資料來源變更時，還是要變更未使用 Entity Framework 的任何應用程式部分。

  • Entity Framework 所使用的資料提供者連接可以與應用程式的其他部分共用，因為 實體架構 會使用 ADO.NET 資料提供者存取資料來源。例如，Entity Framework 是使用 SqlClient 提供者進行存取 SQL Server 資料庫。如需詳細資訊，請參閱 Entity Framework 的 EntityClient 提供者。

通用移轉工作

移轉現有應用程式至 實體架構 的途徑取決於應用程式的類型以及現有資料存取策略。不過，在將現有應用程式移轉至 實體架構 時，一律必須執行下列工作：

Note附註

當您使用 Entity Data Model 工具搭配 Visual Studio 2008 時，便會自動執行所有這些工作。如需詳細資訊，請參閱 HOW TO：使用 Entity Data Model 精靈 (Entity Framework)。

  1. 升級應用程式。

    以舊版 Visual Studio 和 .NET Framework 所建立的專案必須升級為使用 Visual Studio 2008 SP1 和 .NET Framework 3.5 SP1。如需詳細資訊，請參閱 Visual Studio 轉換精靈。

  2. 定義 實體資料模型 (EDM)。

    EDM 會定義概念模型中的實體、資料來源中的結構 (例如資料表、預存程序和檢視表)，以及實體與資料來源結構間的對應。如需詳細資訊，請參閱 HOW TO：以手動方式定義 Entity Data Model (Entity Framework)。

    儲存體模型中定義的類型必須與資料來源中物件的名稱相符。如果現有應用程式將資料公開 (Expose) 為物件，您必須確保概念模型中定義的實體和屬性與這些現有資料類別和屬性的名稱相符。如需詳細資訊，請參閱 HOW TO：自訂 Entity Data Model 以搭配自訂物件運作 (Entity Framework)。

    Note附註

    Entity Data Model Designer 可以用來重新命名概念模型中的實體，使其與現有物件相符。如需詳細資訊，請參閱 ADO.NET 實體資料模型設計工具概觀。

  3. 定義連接字串 (Connection String)。

    實體架構 會在對 EDM 執行查詢時使用特殊格式化的連接字串。此連接字串會封裝有關 EDM 對應檔和資料來源連接的資訊。如需詳細資訊，請參閱 HOW TO：定義連接字串 (Entity Framework)。

  4. 設定 Visual Studio 專案。

    對 實體架構 組件 (Assembly) 和 EDM 的參考必須加入至 Visual Studio 專案。您可以將這些對應檔加入至專案，以確保它們與應用程式一起部署在連接字串中所指示的位置。如需詳細資訊，請參閱 HOW TO：手動設定 Entity Framework 專案。

適用於具有現有物件的應用程式之考量

在將應用程式移轉至 實體架構 的時候，您移轉現有資料類別的方式會取決於這些類別中實作的商務邏輯、自訂方法和屬性驗證。您應該選取下列其中一個方式來處理現有資料類別。

  • 如果資料類別只取得和設定物件屬性，請以 實體資料模型 工具所產生的實體類型來取代現有資料類別。如需詳細資訊，請參閱 HOW TO：使用 Entity Data Model 精靈 (Entity Framework)。

  • 如果資料類別實作自訂驗證程式碼或其他商務邏輯，請將此邏輯移轉至 實體資料模型 工具所產生的部分類別。實體資料模型 工具會產生實體類型做為部分類別，這樣能讓您藉由將現有類別轉換成部分類別，重複使用方法和屬性。當您如此做時，必須從現有應用程式移除所產生之類別中任何重複的屬性。如需如何建立部分類別的詳細資訊，請參閱自訂物件 (Entity Framework)。

    針對資料類別的每個屬性，實體架構 工具會產生名為 OnPropertyNameChanging 和 OnPropertyNameChanged 的部分方法。您可以將現有屬性驗證程式碼移入這些部分方法。如需詳細資訊，請參閱 HOW TO：在屬性變更期間執行商務邏輯 (Entity Framework)。

  • 如果您在現有資料類別中有大量的自訂程式碼或因其他原因而要保留現有資料類別，應該執行下列其中一個動作：

    • 將資料類別修改為繼承自 EntityObject 或 ComplexObject 類別。所有產生的 EDM 類型都繼承自 EntityObject 或 ComplexObject，因此 實體架構 能讓您藉由繼承自這些基底類別 (Base Class) 使用自訂資料類別。這是使用自訂資料類別搭配 EDM 的建議方式。如需詳細資訊，請參閱自訂物件 (Entity Framework)。

    • 將資料類別修改為實作一組介面。若資料類別無法繼承自 EntityObject 或 ComplexObject，才執行這個動作。如需如何實作這些介面的詳細資訊，請參閱自訂物件 (Entity Framework)。

Note附註

當您使用現有資料類別或部分類別搭配 EDM 時，類別的名稱必須與概念模型中定義的實體名稱相符。請使用 Entity Designer 重新命名實體。如需詳細資訊，請參閱 HOW TO：建立和修改實體類型。

適用於使用 ADO.NET 提供者的應用程式之考量

ADO.NET 提供者 (如 SqlClient) 能讓您查詢資料來源，進而傳回表格式資料。資料也可以載入至 ADO.NET 資料集。下列清單說明適用於升級使用現有 ADO.NET 提供者的應用程式之考量：

  • 使用資料讀取器 (Reader) 顯示表格式資料。
    您可以考慮使用 EntityClient 提供者執行 實體 SQL 查詢，並且列舉整個傳回的 EntityDataReader 物件。只有在應用程式使用資料讀取器顯示表格式資料，而且不需要物件服務提供的功能進行將資料具體化為物件、追蹤變更和處理更新時才這麼做。您可以繼續使用對資料來源進行更新的現有資料存取程式碼，不過您可以使用從 EntityConnection 的 StoreConnection 屬性存取的現有連接。如需詳細資訊，請參閱 Entity Framework 的 EntityClient 提供者。

  • 使用資料集。
    在 實體架構 中，物件服務提供的許多功能與資料集提供的相同，包括在記憶體中的持續性 (Persistence)、變更追蹤、資料繫結 (Data Binding)，以及將物件序列化為 XML 資料。如需詳細資訊，請參閱物件服務概觀 (Entity Framework)。

    如果物件服務並未提供應用程式所需的資料集功能，您還是可以使用 LINQ 到 DataSet 來善用 LINQ 查詢的優勢。如需詳細資訊，請參閱 LINQ to DataSet。

適用於將資料繫結至控制項的應用程式之考量

.NET Framework 可讓您封裝資料集、ASP.NET 資料來源控制項等這類的資料來源中的資料，然後將使用者介面項目繫結至那些資料控制項。下列清單說明適用於將控制項繫結至 Entity Framework 資料的考量。

  • 將資料繫結至控制項。
    當您查詢 EDM 時，物件服務會傳回資料做為實體類型執行個體 (Instance) 的物件。這些物件可以直接繫結至控制項，而且此繫結作業支援更新，因此在呼叫 SaveChanges 方法時，會自動把對控制項中的資料 (如 DataGridView 中的資料列) 所做的變更儲存至資料庫。

    如果應用程式列舉查詢的結果，以在 DataGridView 或其他支援資料繫結的控制項類型中顯示資料，您則可以把應用程式修改為將控制項繫結至 ObjectQuery 的結果。

    如需詳細資訊，請參閱將物件與控制項繫結 (Entity Framework)。

  • ASP.NET 資料來源控制項。
    實體架構 包含資料來源控制項，是專為簡化 ASP.NET Web 應用程式中的資料繫結所設計。如需詳細資訊，請參閱 Entity Framework Data Source Control。

其他考量

下列考量可適用於將特定應用程式類型移轉至 Entity Framework 的情況。

  • 公開資料服務的應用程式。
    以 Windows Communication Foundation (WCF) 為架構的 Web 服務和應用程式使用 XML 要求/回應訊息格式公開來自基礎資料來源的資料。實體架構 使用二進位、XML 或 WCF 資料合約序列化 (Serialization) 支援實體物件的序列化。二進位和 WCF 序列化都支援物件圖形的完整序列化。如需詳細資訊，請參閱 Web 服務和 Entity Data Model (應用程式案例)。

  • 使用 XML 資料的應用程式。
    物件序列化能讓您建立 實體架構 資料服務。這些服務為使用 XML 資料的應用程式提供資料，例如以 AJAX 為架構的網際網路應用程式。在這些情況下，請考慮使用 ADO.NET 資料服務。這些資料服務是以 EDM 為架構，並且使用標準代表性狀態轉換 (Representational State Transfer，REST) HTTP 動作 (如 GET、PUT 和 POST) 來為實體資料提供動態存取。如需詳細資訊，請參閱 ADO.NET 資料服務架構。

    實體架構 不支援原生 XML 資料型別，亦即將實體對應至具有 XML 資料行的資料表時，XML 資料行的對等實體屬性會是字串。您可以中斷物件的連接，而且將其序列化為 XML。如需詳細資訊，請參閱序列化物件 (Entity Framework)。

    如果應用程式需要有查詢 XML 資料的功能，您還是可以使用 LINQ to XML 來善用 LINQ 查詢的優勢。如需詳細資訊，請參閱 LINQ to XML。

  • 維護狀態的應用程式。
    ASP.NET Web 應用程式必須經常維護 Web 網頁或使用者工作階段 (Session) 的狀態。ObjectContext 執行個體中的物件可存放於伺服器上的用戶端檢視狀態或工作階段檢視狀態內，以便之後擷取或重新附加至新的物件內容。如需詳細資訊，請參閱附加物件 (Entity Framework)。

另請參閱

概念

部署考量因素 (Entity Framework)
Entity Framework 詞彙

其他資源

Entity Framework 工作