【正文】 omer_name { get。而在本框架中將把參數(shù)customer_name設(shè)計(jì)為存儲(chǔ)過程對(duì)象SelectCustomerByName的一個(gè)屬性，調(diào)用更加方便。(customer_name, 上汽)。這樣的代碼，增加調(diào)用存儲(chǔ)過程的配置。（2）更好的支持存儲(chǔ)過程對(duì)象化訪問和視圖對(duì)象的對(duì)象化訪問。特點(diǎn)如下：（1）本框架支持多數(shù)據(jù)傳輸?shù)哪Ｊ饺鏦eb Service ,WCF , Remoting等。在盡量滿足上面所描述的功能外，ThinkWide框架在結(jié)構(gòu)層次、可擴(kuò)展性、模塊化方面突出了自己的特點(diǎn)。 ThinkWide框架整體結(jié)構(gòu)圖在實(shí)際操作過程中，這些層大都可以單獨(dú)使用。（7）基于容器的分布式服務(wù)工廠,透明的分布式服務(wù)調(diào)用和分發(fā) ?！。?）支持多種數(shù)據(jù)庫源，提供開放的數(shù)據(jù)庫接口。（3）動(dòng)態(tài)實(shí)體類工廠,運(yùn)行時(shí)動(dòng)態(tài)對(duì)象及緩存實(shí)體類接口的實(shí)現(xiàn)類。相對(duì)于NHibernate更加靈活和方便。是一種相對(duì)更加完整的軟件應(yīng)用解決方案，采用了當(dāng)前比較前瞻性的軟件技術(shù)，主要包含數(shù)據(jù)訪問層，數(shù)據(jù)服務(wù)層，數(shù)據(jù)對(duì)象封裝層，業(yè)務(wù)層邏輯，以及配置層，界面表示層等。 框架架構(gòu)設(shè)計(jì)基于以上的不同框架需求提出了一種ThinkWide (下文簡(jiǎn)稱ThinkWide框架)，這是一種支持Net 、C。因此，本框架還需提供一種比較全面和靈活的配置方案。此外由于開發(fā)的業(yè)務(wù)需求千變?nèi)f化，無窮無盡。作為一種ORM框架既要功能強(qiáng)大又要使用簡(jiǎn)單和靈活。通過Web Service ,WCF , Remoting等技術(shù)。傳統(tǒng)的ORM框架主要解決了本地或網(wǎng)絡(luò)數(shù)據(jù)庫的鏈接和讀取，主要在局域網(wǎng)內(nèi)應(yīng)用，無法直接支持跨網(wǎng)絡(luò)協(xié)議的應(yīng)用。 的數(shù)據(jù)訪問功能，可以運(yùn)行在提供了驅(qū)動(dòng)程序的通用關(guān)系數(shù)據(jù)庫上，不依賴特定的關(guān)系數(shù)據(jù)庫，使得整個(gè)系統(tǒng)在不同的關(guān)系數(shù)據(jù)庫管理系統(tǒng)（如SQL Server 和Oracle 等數(shù)據(jù)庫）之間的移植非常的方便。使得開發(fā)人員面對(duì)的數(shù)據(jù)庫是面向?qū)ο蟮模辉偈且粋€(gè)關(guān)系數(shù)據(jù)庫，它不必關(guān)心也根本感覺不到對(duì)象所依賴的表以及表之間的關(guān)系，而是直接以面向?qū)ο蟮姆绞綄?duì)所有應(yīng)用邏輯對(duì)象進(jìn)行存儲(chǔ)、操作?？偠灾?，ORM的功能應(yīng)該盡量使的開發(fā)者能夠減少程序開發(fā)工作中繁瑣的數(shù)據(jù)讀取、保存、傳輸?shù)确矫娴拈_發(fā)量，集中精力實(shí)現(xiàn)應(yīng)用系統(tǒng)的邏輯，而不必在對(duì)象數(shù)據(jù)的存儲(chǔ)上分散過多的精力。（11）支持直接的SQL 查詢?？勺杂蓴U(kuò)展對(duì)其他非主流數(shù)據(jù)庫的支持；（6）提供比較完備的配置方案，包含數(shù)據(jù)庫配置，數(shù)據(jù)傳輸配置，以及業(yè)務(wù)邏輯配置等；（7）支持多種體系結(jié)構(gòu)。諸如對(duì)象查詢操作等經(jīng)常涉及對(duì)象集合的操作，需要提供相應(yīng)的方法同時(shí)返回多個(gè)數(shù)據(jù)集合；（4）事務(wù)的支持。分析各類框架的特點(diǎn)，整合出一個(gè)比較實(shí)用的框架設(shè)計(jì)理念，應(yīng)該支持以下的幾種需求：（1）支持多種數(shù)據(jù)庫，比如主流的數(shù)據(jù)庫MSSQL,Oracle,DB2,My SQL,Access等；（2）對(duì)底層存儲(chǔ)機(jī)制的完全屏蔽。但是其必須需要編寫SQL，容易出錯(cuò)，也不夠自動(dòng)化。讀取數(shù)據(jù)效率較低，不適合統(tǒng)計(jì)查詢系統(tǒng)。但是其較復(fù)雜，學(xué)習(xí)曲線大。（2）需要大量的xml配置文件，維護(hù)的工作量也不小。（1）手寫SQL容易出錯(cuò)，工作量比較大。它實(shí)現(xiàn)一種所謂自動(dòng)提升事務(wù)機(jī)制（Promotable Transaction），會(huì)自動(dòng)根據(jù)事務(wù)中涉及的對(duì)象資源判斷使用何種事務(wù)管理器。e （1）在簡(jiǎn)單(不涉及分布式)事務(wù)中也可以使用聲明式的事務(wù)處理方法，而不必使用容器等設(shè)置。作為正統(tǒng)ORM實(shí)現(xiàn)的一種有益補(bǔ)充。，對(duì)業(yè)務(wù)邏輯實(shí)現(xiàn)人員而言，面對(duì)的是純粹的對(duì)象，這一層與通過 NHibernate等實(shí)現(xiàn)的ORM 而言基本一致，而對(duì)于具體的數(shù)據(jù)操作，NHibernate會(huì)自動(dòng)生成SQL 語句， SQL 語句。也就是說， SQL 執(zhí)行。程序員甚至不需要對(duì) SQL 的熟練掌握，ORM會(huì)根據(jù)制定的存儲(chǔ)邏輯，自動(dòng)生成對(duì)應(yīng)的 SQL 并調(diào)用 接口加以執(zhí)行?？v觀目前主流的 ORM，都對(duì)數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，提供了從實(shí)體類到數(shù)據(jù)庫表的全套映射機(jī)制。然后根據(jù)配置好的數(shù)據(jù)訪問驅(qū)動(dòng)，自動(dòng)執(zhí)行SQL語句。也是它為我們所做最多的工作了。我們需要自己來控制SQL語句，這樣做有好處在于，我們可以更靈活地根據(jù)我們的需求，編寫更加具備性能，功能優(yōu)勢(shì)的SQL語句，但它的缺點(diǎn)同樣明顯，我們還是需要管理和編寫SQL語句。 框架優(yōu)缺點(diǎn)分析，但是它并不是一種很正統(tǒng)的ORM解決方案。對(duì)于多表連查，復(fù)雜的sql實(shí)現(xiàn)比較復(fù)雜，而且有可能需要借助其他方案。NHibernate需要數(shù)據(jù)庫有良好的設(shè)計(jì)和比較完善的約束。 （1）較復(fù)雜，學(xué)習(xí)曲線大。 （3）較好的文檔支持。NHibernate有工具可以直接根據(jù)數(shù)據(jù)庫模式生成對(duì)象類，或者通過在代碼中添加屬性自動(dòng)生成配置文件。程序員往往只需定義好了對(duì)象到數(shù)據(jù)庫表的映射關(guān)系，即可通過NHibernate提供的方法完成持久層操作。 （2）代碼自動(dòng)生成，減少代碼和sql的開發(fā)量，使開發(fā)人員擺脫開sql，緩存等底層。 NHibernate對(duì)數(shù)據(jù)庫結(jié)構(gòu)提供了較為完整的封裝，它將數(shù)據(jù)庫模式映射為較完全的對(duì)象模型，支持封裝，繼續(xù)機(jī)制，功能較強(qiáng)大，比一般的ORM靈活性高。雖然NHibernate框架很強(qiáng)大，封裝也比較全面，有它優(yōu)秀的地方，但是在某些方面中還是有不足的地方，以下總結(jié)了NHibernate框架的優(yōu)缺點(diǎn)。（8）TransactionFactory：事務(wù)實(shí)例的工廠。從底層的IDbConnection抽象而來。一個(gè)Session在某些情況下可能跨越多個(gè)Transaction事務(wù)。這些可能是剛剛被程序?qū)嵗?，還沒有來得及被持久化，或者是被一個(gè)已經(jīng)關(guān)閉的Session實(shí)例化。一旦Session被關(guān)閉，它們都將從Session中取消聯(lián)系，可以在任何程序?qū)幼杂墒褂茫ū热?，直接作為傳送到表現(xiàn)層的DTO,數(shù)據(jù)傳輸對(duì)象）。（4）持久化對(duì)象(persistent)其集合(Collections):生命期較短的單線程的對(duì)象，包含了持久化狀態(tài)和商業(yè)功能。也是Transaction的工廠?？梢猿钟幸粋€(gè)可選的（第二級(jí)）數(shù)據(jù)緩存，可以在進(jìn)程級(jí)別或集群級(jí)別保存的可以在事物中重用的數(shù)據(jù)。NHibernate體系結(jié)構(gòu)圖如下： NHibernate體系結(jié)構(gòu)（1）供持久化服務(wù)（和持久化的對(duì)象）。NHibernate 為你處理這些，遠(yuǎn)勝于你不得不寫SQL去從數(shù)據(jù)庫存取對(duì)象。NHibernate是一個(gè)目前應(yīng)用的最廣泛的開放源代碼的對(duì)象關(guān)系映射框架，使得程序員可以隨心所欲的使用對(duì)象編程思維來操縱數(shù)據(jù)庫。對(duì)于以數(shù)據(jù)為中心的程序，開發(fā)人員往往是在數(shù)據(jù)庫中使用存儲(chǔ)過程來實(shí)現(xiàn)商業(yè)邏輯，這種情況下NHibernate可能不是最好的解決方案，并且能夠?qū)崿F(xiàn)OO業(yè)務(wù)模型和商業(yè)邏輯的中間層應(yīng)用，NHibernate是最有用的。 NHibernate 框架優(yōu)缺點(diǎn)分析，用來把對(duì)象模型表示的對(duì)象映射到基于SQL的關(guān)系模型數(shù)據(jù)結(jié)構(gòu)中去。當(dāng)前主要流行的ORM框架：。 第三章 ThinkWide框架的設(shè)計(jì)第三章 ThinkWide框架的需求分析與設(shè)計(jì) 框架需求分析對(duì)于一個(gè)ORM框架，基本的功能需求歸納起來就是創(chuàng)建、讀、寫、刪除對(duì)象的操作。事實(shí)上WCF遠(yuǎn)非簡(jiǎn)單的并集這樣簡(jiǎn)單，它是真正面向服務(wù)的產(chǎn)品，它已經(jīng)改變了通常的開發(fā)模式）因此，利用WCF，就可以解決包括安全、可信賴、互操作、跨平臺(tái)通信等等需求。 從功能的角度來看，WCF完全可以看作是ASMX，.Net Remoting，Enterprise Service，WSE，MSMQ等技術(shù)的并集。同時(shí)，面向服務(wù)架構(gòu) (ServiceOriented Architecture) 也開始盛行于軟件工業(yè)中，因此微軟重新查看了這些通信方法，并設(shè)計(jì)了一個(gè)統(tǒng)一的程序開發(fā)模型，對(duì)于數(shù)據(jù)通信提供了最基本最有彈性的支持，這就是 Windows Communication Foundation概念。3. WCF技術(shù)Windows Communication Foundation (WCF) 是由微軟發(fā)展的一組數(shù)據(jù)通信的應(yīng)用程序開發(fā)接口，由 .NET Framework 開始引入，與 Windows Presentation Foundation 及 Windows Workflow Foundation 一起成為新一代 Windows 操作系統(tǒng)以及 WinFX 的三個(gè)重大應(yīng)用程序開發(fā)類庫。但必須注意的是，客戶端在獲取服務(wù)器端對(duì)象時(shí)，并不是獲得實(shí)際的服務(wù)端對(duì)象，而是獲得它的引用。遠(yuǎn)程對(duì)象代碼可以運(yùn)行在服務(wù)器上（如服務(wù)器激活的對(duì)象和客戶端激活的對(duì)象），然后客戶端再通過Remoting連接服務(wù)器，獲得該服務(wù)對(duì)象并通過序列化在客戶端運(yùn)行。首先，客戶端通過Remoting，訪問通道以獲得服務(wù)端對(duì)象，再通過代理解析為客戶端對(duì)象。然而在某些情況下，我們需要跨過應(yīng)用程序域，與另外的應(yīng)用程序域進(jìn)行通信，即穿越邊界。如果不采用進(jìn)程間通信（RPC）機(jī)制，則在一個(gè)進(jìn)程中執(zhí)行的代碼就不能訪問另一進(jìn)程。為什么呢？在Windows操作系統(tǒng)中，是將應(yīng)用程序分離為單獨(dú)的進(jìn)程。Remoting 提供了一種允許對(duì)象通過應(yīng)用程序域與另一對(duì)象進(jìn)行交互的框架。Remoting，簡(jiǎn)而言之，我們可以將其看作是一種分布式處理方式。實(shí)際上，WebService的主要目標(biāo)是跨平臺(tái)的可互操作性。Web Service可以執(zhí)行從簡(jiǎn)單的請(qǐng)求到復(fù)雜商務(wù)處理的任何功能。也是一種新的應(yīng)用程序分支，具有支持自包含、自描述、模塊化的應(yīng)用功能。 Services技術(shù)Web Services是由企業(yè)發(fā)布的完成其特定商務(wù)需求的在線應(yīng)用服務(wù)，其他公司或應(yīng)用軟件能夠通過Internet來訪問并使用這項(xiàng)在線服務(wù)。 遠(yuǎn)程數(shù)據(jù)訪問技術(shù)遠(yuǎn)程數(shù)據(jù)訪問技術(shù)經(jīng)歷了幾十年的發(fā)展逐漸成熟，從一開始的RAD（Remote Data Access）到分布式的DCOM(Microsoft Distributed Component Object Model)等。 ，比如連接MS SQL Server數(shù)據(jù)庫時(shí)，使用SqlConnection,SqlCommand等一組類，在連接Oracle數(shù)據(jù)庫時(shí)使用OracleConnection，OracleCommand等一組類。（5）DataAdapter類，用于填充DataSet類的數(shù)據(jù)，或者將DataSet中的數(shù)據(jù)保到數(shù)據(jù)庫等功能。它包括多個(gè)DataTable對(duì)象，而DataTable包含列和行，就象一個(gè)普通的數(shù)據(jù)庫中的表。 （3）DataReader類，用于讀取Command對(duì)象的SELECT語句得到的結(jié)果集。Connection類會(huì)被Command等類使用，這樣就能夠知道是在哪個(gè)數(shù)據(jù)源上面執(zhí)行命令。這些類庫稱為Data Providers，并且通常是以與之交互的協(xié)議和數(shù)據(jù)源的類型來命名的。一些老式的數(shù)據(jù)源使用ODBC協(xié)議，許多新的數(shù)據(jù)源使用OleDb協(xié)議，并且現(xiàn)在還不斷出現(xiàn)更多的數(shù)據(jù)源。然而并沒有與此相關(guān)的一系列類來完成這樣的工作。事實(shí)上，接受數(shù)據(jù)的組件不一定要是ADO .NET組件，它可以是基于一個(gè)Microsoft Visual Studio的解決方案，也可以是任何運(yùn)行在其它平臺(tái)上的任何應(yīng)用程序[25]。,并支持RICH XML。 .Net平臺(tái)下ORM底層數(shù)據(jù)訪問技術(shù)ORM是一種架構(gòu)在底層數(shù)據(jù)訪問技術(shù)之上的中間層。對(duì)象持久化的基礎(chǔ)是對(duì)象關(guān)系映射理論，如今，面向?qū)ο笏枷胍呀?jīng)普及并被普遍采用，而且業(yè)務(wù)數(shù)據(jù)的建模采用了面向?qū)ο蠼７椒?，但是目前大多?shù)應(yīng)用系統(tǒng)中使用的是關(guān)系數(shù)據(jù)庫，數(shù)據(jù)的存儲(chǔ)也采用關(guān)系模型，這就需要一個(gè)從對(duì)象模型到關(guān)系模型的映射過程。因此當(dāng)部分應(yīng)用需求變更時(shí),首先,系統(tǒng)修改可以不涉及需求不變更的部分。在映射應(yīng)用對(duì)象時(shí),除關(guān)系映射規(guī)范化后可能出現(xiàn)一對(duì)多的表映射外,大多數(shù)應(yīng)用對(duì)象與表對(duì)象是一一對(duì)應(yīng)的。除了數(shù)據(jù)庫表對(duì)象與應(yīng)用模塊對(duì)象一一對(duì)應(yīng)外,在邏輯對(duì)象模型中我們沒有設(shè)計(jì)多重繼承的泛化關(guān)系,所以這樣得到的數(shù)據(jù)庫結(jié)構(gòu)基本上是由父表類和子表類構(gòu)成的樹型層次結(jié)構(gòu),表類間很少有繼承以外的復(fù)雜關(guān)系,是一個(gè)符合局部化原則的結(jié)構(gòu),從而使數(shù)據(jù)庫表數(shù)據(jù)破壞的影響控制在局部范圍且便于修復(fù),給系統(tǒng)開通后的數(shù)據(jù)庫日常維護(hù)工作帶來便利。特別是對(duì)多數(shù)不了解業(yè)務(wù)的程序開發(fā)人員來說,這種將應(yīng)用對(duì)象與相應(yīng)的數(shù)據(jù)對(duì)象封裝在對(duì)象統(tǒng)一體中的設(shè)計(jì)方法,大大減輕了程序?qū)崿F(xiàn)的難度,使他們只要知道加工的數(shù)據(jù)及所需的操作即可,而且應(yīng)用程序大多雷同,可以多處繼承由設(shè)計(jì)人員抽象出來的、預(yù)先開發(fā)好的各種物理級(jí)超類。由于實(shí)現(xiàn)了應(yīng)用模塊對(duì)象對(duì)數(shù)據(jù)庫對(duì)象的完全映射,數(shù)據(jù)庫邏輯模型可以自然且直接地模擬現(xiàn)實(shí)世界的實(shí)體關(guān)系。它能有效避免繁瑣的數(shù)據(jù)訪問細(xì)節(jié)，對(duì)象和關(guān)系的行列轉(zhuǎn)換都由ORM完成，不需要寫過多的數(shù)據(jù)訪問細(xì)節(jié)代碼，面向?qū)ο蟮母拍詈完P(guān)系數(shù)據(jù)之間的映射可抽象成為單個(gè)組件的職責(zé)，獨(dú)立于應(yīng)用程序之外。內(nèi)存中的對(duì)象之間存在關(guān)聯(lián)和繼承關(guān)系，而在數(shù)據(jù)庫中，關(guān)系數(shù)據(jù)無法直接表達(dá)多對(duì)多關(guān)聯(lián)和繼承關(guān)系。面向?qū)ο蟮拈_發(fā)方法是當(dāng)今企業(yè)級(jí)應(yīng)用開發(fā)環(huán)境中的主流開發(fā)方法，關(guān)系數(shù)據(jù)庫是企業(yè)級(jí)應(yīng)用環(huán)境中永久存放數(shù)據(jù)的主流數(shù)據(jù)存儲(chǔ)系統(tǒng)。本質(zhì)上就是將數(shù)據(jù)從一種形式轉(zhuǎn)換到另外一種形式。 ORM 技術(shù)產(chǎn)生的主要原因ORM是一種為了解決面向?qū)ο笈c關(guān)系數(shù)據(jù)庫存在的互不匹配的現(xiàn)象的技術(shù)。克服了傳統(tǒng)數(shù)據(jù)模型的主要缺點(diǎn)?？傊?，面向?qū)ο髷?shù)據(jù)模型比之傳統(tǒng)數(shù)據(jù)模型的根本區(qū)別是面向?qū)ο竽Ｐ褪敲嫦蛑苯討?yīng)用的。在某些情況中實(shí)體－聯(lián)系模型和關(guān)系模型都不能夠方便的建立數(shù)據(jù)建模，而面向?qū)ο髷?shù)據(jù)模型克服了傳統(tǒng)數(shù)據(jù)模型的缺陷。但在某些應(yīng)用下使用關(guān)系模式相當(dāng)繁瑣和復(fù)雜比如嵌套或者可以繼承的對(duì)象實(shí)體等，因而在這些情況下數(shù)據(jù)庫應(yīng)用不能充分發(fā)揮。數(shù)據(jù)庫系統(tǒng)是為了管理大量的數(shù)據(jù)而產(chǎn)生。一般只提供一些簡(jiǎn)單的數(shù)據(jù)類型，如整型、實(shí)型等一些預(yù)定義好的類型，并不提供一些特殊新類型的定義和生成能力。關(guān)系模型不能由一張表表達(dá)出更加復(fù)雜對(duì)象的語義，這就限制了它在數(shù)據(jù)類型較多、較復(fù)雜的領(lǐng)域的應(yīng)用。關(guān)系模型所表達(dá)的實(shí)體之間的聯(lián)系不是顯式的，而是隱含在關(guān)系的公共屬性中的，這就使得用戶無法方便得到全局的邏輯體系結(jié)構(gòu)。其次，關(guān)系數(shù)據(jù)庫不能以自然地方式表達(dá)實(shí)體之間