Visual Studio 2012

  • 發行項

利用 Visual Studio LightSwitch 2012 構成資料

Jan Van der Haegen

 

Visual Studio LightSwitch 2011 年年中的最簡單的方法來構建商務應用程式的桌面或雲時最初被釋放。 雖然它很快就通過了許多 IT 頭腦的人，一些專業開發人員很快結束 LightSwitch 可能不准備好企業世界。 畢竟，快速應用程式開發技術可能會開始新的和小的現在，應用好方法，但不幸的是，歷史已經證明這些快速建立的應用程式不能擴展好一旦他們成長大，它們需要很大的精力與現有的舊式系統進行交互操作，他們不適應快節奏的技術變革，他們不能處理企業如波塞裝置或許多併發使用者的要求。 最重要的是，在開放的標準，例如 rest 風格的服務和 HTML 客戶正在通過幾乎每一個大型的 IT 組織的世界裡，誰會願意被捲入任何封閉的格式？

LightSwitch 2012 年來臨的發行版本，我以為那是一個完美的時期，說服一些朋友 （專業開發人員和軟體結構設計師），把他們的偏見，一邊和 （重新） 評估 LightSwitch 如何處理這些現代的要求。

結果呢？ 原來 LightSwitch 2012 不只是處理所有這些要求，它絕對釘他們。

瞭解 Visual Studio LightSwitch

LightSwitch 是基於設計器的補充到 Visual Studio 2012 年協助與以資料為中心的服務和應用程式一起工作。 當使用一個 LightSwitch 專案，Visual Studio IDE 更改到開發環境中只有三個主要編輯 （在所謂的"邏輯模式")：實體設計器、 查詢設計器和螢幕設計器。 這些編輯側重于快速獲取結果，非常直觀、 快速、 便於使用的。 這給 LightSwitch 開發人員的生活增添了一些明顯的好處：

  • 第一，它隱藏管道 （重複代碼通常與發展這些資訊系統相關聯）。 便於使用編輯的意思是快速發展、 快速發展，意味著生產開發和生產開發商意味著更多的業務價值的。 或者，如斯科特靜態所說，"你規模很大的東西的方式你做的是盡可能少，你可以盡可能多。 事實上，做得越少，你可以做的更多"（請參見 bit.ly/InQC2b)。
  • 第二，，或許最重要的是，非技術性的人，從功能分析師到小企業主向 Microsoft Access 或 Microsoft Excel"地產商"— — 通常被稱為公民開發商 — — 誰知道裡面出來的業務、 可以一步和説明開發應用程式，或甚至完全開發。 編輯隱藏從那些喜歡以避免它們和默默地指導應用程式設計器來應用最佳做法，例如將在可重複使用的域模型中，域邏輯封裝保持使用者介面回應以外，在 UI 執行緒的執行緒上執行業務邏輯或在用戶端模型-視圖-ViewModel （MVVM） 發展模式應用的技術選擇。
  • 最後，這些編輯器其實別類直接編輯。 相反，他們對 XML 檔包含中繼資料 （LightSwitch 標記語言），然後由自訂 MSBuild 任務用於在編譯過程中生成的代碼的操作。 這有效地釋放所做的任何技術選擇的業務邏輯的投資。 例如，曾在 1.0 版的 LightSwitch 專案將使用 WCF RIA 服務的用戶端和伺服器之間的所有通信，而那同一專案現在編譯使用開放式資料協定 (OData) 而服務 （更多關於 OData 以後）。 這是自我調整不斷變化它景觀，應用程式可以獲取到。

設計資料

設計與 LightSwitch 的資料可以被視為等同于專業開發人員的詞彙中創建域模型。 IDE 將首先詢問您關於"開始的資料，"特別是要用來存儲此資料。 可以使用兩種可能的答案。 SQL Server 或 Windows Azure SQL 資料庫，可以選擇"創建新表"的案例 LightSwitch 使用實體框架在 SQL 緊湊 （在調試應用程式） 時，創建所需的表。 或者，您可以選擇在現有的資料來源，如 SharePoint、 OData 服務，現有的資料庫或一個 WCF RIA 服務元件設計您的實體。 後者兩個可以真正説明您繼續工作的一組現有的資料從舊式應用程式，但它公開通過全新的服務或應用程式中的現代和開放標準。

作為一個例子，可以把現有的 OData 服務 （可在 odata.org/ecosystem 是一個廣泛的示例清單），並導入一個新的 LightSwitch 應用程式的一個或多個實體。

圖 1 顯示您從羅斯文資料來源雇員實體如何首先表示在設計器中的實體。 與幾次滑鼠點擊和少量的編碼的工作哪裡需要，您可以重新設計的幾種方式的實體 （最終結果可以發現在圖 2)。 這些工作包括：

  • 重命名屬性或重新排列它們 （推介和主管）。
  • 選擇設置列出應只接受有限的數量的 (城市、 區域、 郵遞區號、 國家、 標題和 TitleOfCourtesy） 的預定義值的屬性。
  • 添加新的或計算屬性 （NameSummary）。
  • 以上 （BirthData，雇傭日期、 單位電話、 照片和 PhotoPath） 的屬性的資料類型映射更為詳細的業務類型。

The Entity Designer After Importing from an Existing OData Service
從現有的 OData 服務導入後圖 1 的實體設計器

The Same Employee Entity After Redesign
圖 2 相同的雇員實體後重新設計

LightSwitch 瞭解常用的業務類型的電子郵件地址和電話號碼，如大型集和更多可以發現許多可用的擴展，或您可以創建您自己的業務類型，通過 LightSwitch 可擴充性專案。 對基礎資料類型，業務類型增加具有特定的特徵，如專門驗證 （例如，檢查電子郵件或 Web 位址格式的） 的屬性和特定的擴充屬性 （電話號碼業務類型的電話號碼格式），和經常會專門用於控制項 （預設） 代表或交互的用戶端應用程式中的屬性。

實體是幾乎從來不完全無關。 使用實體設計器，您可以設計不同實體之間的關係在需要的地方。 這些關係將會執行所有圖層上 — — 通過在用戶端和中介層中的代碼和設計將存儲在內部 （一種"新"） 的實體時的資料庫中的外鍵 （如 SQL 結構緊湊、 SQL Server 或 Windows Azure SQL 資料庫的資料來源。

然而，LightSwitch 的一個真正強大功能是在現有的資料來源，可以定義新的關係。 當試圖前進與現有資料集，如 XML 檔或舊和格式不正確的資料庫，沒有索引、 鍵或適當的關係，這是尤其有用。 這些所謂的虛擬關係將其實不必改變舊資料源中用戶端和中介層上執行。 更強大的是可以定義不同的資料來源中的資料實體之間的這些虛擬的關係。

例如，通過按右鍵在解決方案資源管理器並選擇添加表中的資料來源，您可以創建一個新的假日實體將存儲在一個新的資料庫，已從羅斯文 OData 服務的雇員實體與虛擬關係中 （請參閱圖 3)。

Virtual Relationships over Different Data Sources
圖 3 虛擬關係在不同的資料來源

創建一個假期跟蹤應用程式通過這種方式是 LightSwitch 如何説明你打破邊界的只是一個應用程式中使用資料提供額外的價值，在另一個很好的例子。

塑造的資料

LightSwitch 嘗試保持入門到最低，這樣可以極大地加快發展初期所需的代碼的數量。 資料服務真正是準備公開之前，它通常將需要一些調整和修改，以塑造企業內部資料。 這通常是容易表達比通過編輯器中的代碼中。

對於每個可想像到的事件，LightSwitch 已經可以從設計器中的寫入代碼按鈕訪問的擴充點 （請參見圖 4)。 根據是否在伺服器上，在用戶端或兩層，將調用您的代碼這將生成方法存根 (stub)，您可以實現您自訂的代碼中任意一種用戶端，共同或伺服器 LightSwitch 專案的子專案。

LightSwitch Supports Many Extension Points
圖 4 LightSwitch 支援許多擴充點

繼續假期跟蹤應用程式的示例，您可以使用這些代碼擴充點來初始化一個實體。 例如，下面的代碼將自動分配批准假期的人作為雇員的主管或批准假期，如果這個人有沒有主管：

public partial class ApplicationDataService
{
  // Initializing a new Holiday - server only
  partial void Holidays_Inserting(Holiday entity)
  {
    if (entity.Employee.Supervisor != null)
      entity.ApprovalBy = entity.Employee.Supervisor;
    else
      entity.Approved = true;
  }       
}

同樣，這些代碼擴充點可以説明您編寫的自訂驗證代碼超出該屬性的業務類型的已驗證：

public partial class Holiday
{
  // Determine if an "EndDate" is valid - executes client and server
  partial void EndDate_Validate(EntityValidationResultsBuilder results)
  {
    if (StartDate > EndDate)
      results.AddPropertyError("End date must follow the start date");
  }
}

除了自訂驗證和商務規則，LightSwitch 還附帶了一種基於角色和許可權的內置、 可選的存取控制模型。 檢查存取控制可以完成從這些代碼可擴充性點以及兩個垂直和水準。

垂直的存取控制是使用者的在您將限制每個螢幕、 實體或屬性基於當前登錄的許可權。 例如，下面的代碼將限制到只有那些在本組織，例如人力資源的某一個部門內員工的批准過程：

public partial class Holiday
{
  // Determine if "Approved" can be modified by the user -
  // executes client and server
  partial void Approved_IsReadOnly(ref bool result)
  {
    result = !Application.User.HasPermission("ApproveHolidays");
  }
}

在您將篩選哪些記錄是對最終使用者可見水準的存取控制。 請注意，在伺服器層上運行此代碼已不允許由最終使用者訪問的意義資料沒有通過導線發送：

public partial class ApplicationDataService
{
  // Filtering out records - runs on the server only
  partial void Holidays_Filter(ref Expression<Func<Holiday, bool>> filter)
  {
    if (!Application.Current.User.HasPermission("ViewAllHolidays"))
      filter = holiday => holiday.Employee.NameSummary == 
        Application.Current.User.FullName ||
        Application.Current.User.FullName == holiday.ApprovalBy.NameSummary;
   }
}

水準的存取控制，也被稱為行級安全，是 Visual Studio 2012 年 LightSwitch 的重要補充。

首先，篩選器是在伺服器上執行。 這將限制可以毫無必要地傳輸每個調用因為並不允許使用者放在第一位與這些行進行交互的資料量。 在垂直的存取控制、 最終使用者仍可看到資料，即使他不能與它交互因為控制項為唯讀，或在違反操作的情況下拋出異常。 然而，在水準的存取控制，多餘的資料完全從最終使用者隱藏。

這將我們帶入另一個強大的使用行級安全性：它可以只向特定的使用者或組織授予部分的整個資料集的擁有權。 這使您可以創建一個應用程式，只需安裝一次，並可以提供訪問到不同的組、 公司、 個人或組織。 他們每個人都作為租客，他們都使用相同的用戶端應用程式和相同的服務，但只有自己的資料切片。 這些租戶的裝置大大所有締約方降低託管成本，並提供其他福利，例如在一個中央位置，如雲只需一次更新的能力。 那些有幸支出接連幾個小時到現場伺服器更新安裝緊急修補程式的安裝後撥入的人可能會首先承認這些租戶功能 LightSwitch 2012 年的力量。

公開資料

當一家公司的資料的價值思考收集時、 很多人傾向于認為這件事僅以使用資料的產品。 然而，收集和分析資料的廣泛類別變得比以往任何時候更有價值。 當從思洛儲存體的單個應用程式釋放出來，並正確地對待，分析和資料採礦可以提供額外收入超越傳統的基於產品的商業模式。 為此工作，是重要的是要樹立開放的標準，如 OData 協定，用於生成 LightSwitch 的專案時自動生成的服務上。

這裡是總結從 OData odata.org:

"OData，短，打開資料協定，是一種 Web 協定用於查詢和更新資料 ... ...OData 通過應用和基礎上 （打開的） 的 Web 技術，如 HTTP、 原子發佈協定和 JSON 做到這一點 ... ...OData 是符合 Web 的工作方式 — — 它使 Uri 的資源識別深承諾並提交到一個基於 HTTP 的、 統一的介面，與這些資源 （就像 Web） 進行交互。 這對核心 Web 原則的承諾允許 OData，讓各個範圍廣泛的用戶端、 伺服器、 服務和工具的資料整合和互通性的一個新的水準。

換句話說，OData 正在實施一項服務，可以進行交互使用簡單 HTTP 動詞和資源識別碼 （或 Url）。 OData 服務可以消耗從幾乎任何用戶端的技術，並在其最簡單的使用，這意味著服務可以甚至流覽與一個 HTTP"Get"請求，從 Web 瀏覽器，例如，通過鍵入 Web 位址作為在下列方面：

HTTP://services.odata.org/Northwind/Northwind.svc/Customers?$filter=

替換 （公司名稱、 20%"、） eq'AlfredsFutterkiste'

此類 URL 總是組成的服務根 URL （服務的端點），資源路徑 （實體的名稱） 和查詢選項可選）。 請注意後者使服務本身相當不可知論者的使用方式 ； OData 協定具有廣泛的查詢語言，可以用來進行排序或篩選資料通過 URL，但調用方需要它。 您可以找到完整的營辦商在集 bit.ly/LSiPAj。

當你設計的 LightSwitch 資料服務，你意識到將消耗資料的方式時，您還可以利用的查詢設計器來創建發佈，方便您自己前的查詢。 圖 5 顯示了一個簡單的查詢返回僅在本年度開始，未經批准的假期。 請注意如何查詢的源是整個假期集，當然，將會由先前設置的代碼中的篩選器 prefiltered。

Using the Query Designer for a Simple Query
使用一個簡單的查詢，查詢設計器的圖 5

花一些時間的實體設計器和查詢設計器之後, 您可以隨時可以部署 OData 服務。 這可以通過直接從 Visual Studio IDE LightSwitch 專案在解決方案資源管理器中按右鍵，然後從內容功能表中選擇"發佈..."的選項。

這就提出了 LightSwitch 發佈應用程式精靈 （見圖 6)，用，您可以設置一些最後的特定于應用程式的屬性如所需的連接字串，身份驗證類型 （無、 使用者名和密碼組合或 Windows 身份驗證），應用程式管理員帳戶和安裝 （它可以安裝包或導致直接發佈到 IIS 或 Windows Azure 從 IDE 中） 的目標。 最後一個選項尤其是已經看到一些巨大的改進過去的幾個月，這使得您的資料服務部署到雲計算快速、 無需擔心的經驗。

The LightSwitch Publish Wizard
圖 6 LightSwitch 發佈嚮導

通過採用開放標準，可以用來與此資料服務進行交互的用戶端的一組是一個幾乎每個最終使用者已經有可用。 如 Microsoft Excel 試算表應用程式允許資料服務並消耗變成 PowerPivot 表和圖，而不需要任何編碼 （請參見圖 7)。 (附註：PowerPivot，到 2013 年辦公室，內置是獨立的、 自由的附加到 Office 2010）。您可以找到有關在此分步演練 bit.ly/xETG0V。

Consuming a LightSwitch OData Service in Excel
圖 7 使用 Excel 中的 LightSwitch OData 服務

建立用戶端

LightSwitch 的另一個關鍵好處是您可以使用相同的 IDE 體驗生成用戶端應用程式。 LightSwitch 支援胖用戶端 （Silverlight 5，在瀏覽器中或出的瀏覽器） 和移動伴侶應用 （HTML5） 具有相同的設計速度，它提供了在伺服器端，或甚至更快。 請注意創建 HTML5 的應用程式的能力才可用在預覽版本中，但最終的 Visual Studio 2012 釋放後將作為一個載入項提供。

若要開始，請按一下實體設計器或查詢設計器中的添加螢幕按鈕。 這將會出現一個嚮導，您可以在其中選擇一個螢幕的範本，可以是許多內置範本或一個您自己創建的或從可用的擴展下載之一。

選擇您的螢幕資料 （假期實體設置） 和範本 （清單和詳細資訊螢幕） 將快速生成所需的螢幕佈局，並在螢幕設計器中打開它。 然後，您可以啟動到佈局控制項的一些初步修改或更改哪些控制項用於完全。 LightSwitch 不會一份好工作的推斷所需的控制項，使用基於業務類型的任何屬性，例如，對於出生日期屬性，使用日期選擇器，但你可以自由地將其更改為另一個 LightSwitch 控制項，或者其中一個提供開箱即用，或從可用的擴展下載。 或者，您可以讓你無限的定制的 XAML （或 JavaScript 和 CSS） 野生運行的技能。 在這一點上，準備構建和運行的 F5 按鈕按一下該應用程式。

正如您看到的圖 8，應用程式是潔淨、 直觀、 功能齊全。 但是，不要讓的方便，它創建您相信它的不完整的把戲。 例如，根據封面，它使用高級的版本的 MVVM，基於運行時解釋我覆蓋線上的 2012 年 4 條，"LightSwitch MVVM 模式"中的中繼資料 （msdn.microsoft.com/magazine/hh965661)。 為此，在 Visual Studio 內部用來做初步設計的螢幕設計器可以使在應用程式內通過按一下右下方，設計螢幕連結，以便您可以查看中繼資料進一步修改應用程式在偵錯模式下運行時。 然後可以返回到該專案保存這些修改。

A Simple LightSwitch Client Application
圖 8 簡單的 LightSwitch 用戶端應用程式

同時進一步探索的 LightSwitch 用戶端體系結構，你會發現有很多更多的技術奇跡來發現。 例如，控制項或螢幕會自動成為唯讀或隱藏如果你缺少編輯基礎實體的許可權。

您不再需要擔心引發 NotifyPropertyChanged 事件同樣方便是你自己，才能綁定能夠正常工作。 如果最終使用者更改雇員實體中的家族名稱屬性，例如，控制項綁定到計算的 fullname 屬性 （基於系列名稱屬性中，當然） 將自動更新以顯示新值。

更改屬性的發言：在用戶端使用的模型都實際上"雙調度員物件"來説明處理業務邏輯同時保持使用者介面回應。 從使用介面執行緒，你可以簡單的賦值給屬性的值。 這將內部發送一個通知，已經上了第二個執行緒，稱為邏輯執行緒中的加權的優先。 一旦處理完成的業務邏輯，相同的事件通知系統用於告知，最終的最終結果在 UI 執行緒，並相應地更新使用者介面。

我想要共用的關於用戶端一個最後一個有趣的事實來自非常活躍 Visual Studio LightSwitch 團隊博客，解釋每個螢幕實際上表示一個工作單元的 （請參見 bit.ly/9vENdF)。 每個螢幕都有其自己的資料的工作區，它與由該初始螢幕，如快顯視窗或實體的詳細資訊螢幕打開任何子螢幕共用。 直到最終使用者決定保存或放棄他們都做的所有更改都保存在本地。 這意味著通過打開螢幕的兩倍 （允許多個實例預設禁用的但可以在從螢幕設計器的屬性視窗中啟用），您可以類比 LightSwitch 如何處理不同的使用者併發修改一些資料，然後將它們保存在同一時間 （請參閱圖 9)。

Handling Concurrent Modifications
圖 9 處理併發修改

如果你想知道如何好 LightSwitch 處理這一點，正如我在導言中說，它不只是處理所有這些要求，它絕對釘他們。

Jan Van der Haegen 是綠色的福將咖啡變成軟體。 他是一個愛的丈夫，掌握國際隊的中心比利時和如此沉迷于任何.net 技術學習的驕傲 scrum — — 尤其是 Visual Studio LightSwitch — — 他保持一個博客，他編碼的實驗。 您可以查找在他最新的冒險經歷 switchtory.com/janvan。

由於下面的技術專家，檢討這篇文章：喬粘結劑和貝斯馬