【文章內(nèi)容簡介】 信的形式多次通知患者?；颊呷绻惺聼o法就診，通過發(fā)送短信，經(jīng)過醫(yī)師或護士同意，還可二次預(yù)約就診時間。 廣東省衛(wèi)生廳副廳長廖新波認為，預(yù)約是提高醫(yī)院知名度、提高醫(yī)生知名度、提高醫(yī)院效益 和符合就診者意愿的工作，預(yù)約工作做得好，可以實現(xiàn)醫(yī)患雙方的共贏。對于目前預(yù)約和排隊并存并出現(xiàn)矛盾的現(xiàn)狀，他建議，醫(yī)院要把每天的預(yù)約單按照診室號夾在門口，目的是讓就診者知道自己處于這位醫(yī)生接診序列的什么位置，同時也宣示醫(yī)院“ 公平對待每一個就診者 ” 的服務(wù)理念。醫(yī)院管理者要確立預(yù)約是門診掛號的主渠道的理念，開始從部分開放預(yù)約診號到全面開放，最后逐步實行全號源的免費預(yù)約。 [13] 本文結(jié)構(gòu)安排 為了使您在短時間內(nèi)了解該論文，特介紹論文內(nèi)容如下 : 第一章 緒論 介紹論文的選題背景、發(fā)展現(xiàn)狀、所做工作及論文的結(jié) 構(gòu)安排。 .Net 信息交流平臺系統(tǒng) 源碼及文檔下載地址： 第二章 相關(guān)技術(shù)及工具介紹，介紹了本設(shè)計作品所使用到的技術(shù)，工具及數(shù)據(jù)庫 第三章 系統(tǒng)需求分析 主要對開發(fā)網(wǎng)站進行需求分析，邏輯模型設(shè)計，概念模型設(shè)計，數(shù)據(jù)庫的建立與連接。及相關(guān)功能代碼介紹 第四章 總結(jié) 對整個設(shè)計過程的總結(jié) 第二章 相關(guān)技術(shù)及工具介紹 系統(tǒng)基于 Windows 平臺，采用 C語言 編程和 SQLServer 數(shù)據(jù)庫技術(shù)，界面使用 VS2020 設(shè)計動態(tài)網(wǎng)頁。系統(tǒng)包含前臺操作與后臺管理，前臺用戶可以進行專家查看、預(yù)約查詢與修改、個人信息修改、密碼修改等操作 。后臺包括用戶管理、專家管理、預(yù)約管理及系統(tǒng)管理等功能。 界面簡單，操作使用方便。 硬件要求： 最低配置要求如下： 386DX 機型； 1GB 硬盤容量； 16MB 內(nèi)存； 640 480顯示卡 及 VGA 彩顯 ； 中文 Windows98 操作系統(tǒng)。 人機界面友好，適用于大部分人群，哪怕是計算機知識少的人群。工作人員只須按時對系統(tǒng)進行更新、維護便可保證預(yù)約的有效性、可靠性。 本系統(tǒng)采用三層架構(gòu)來設(shè)計的，如下圖 .Net 信息交流平臺系統(tǒng) 源碼及文檔下載地址： 三層架構(gòu) (3tier application) 通常意義上的三層架構(gòu)就是將整個業(yè)務(wù)應(yīng)用劃分為：表現(xiàn)層（ UI）、業(yè)務(wù)邏輯層（ BLL）、數(shù)據(jù)訪問層（ DAL）。區(qū)分層次的目的即為了“高內(nèi)聚，低耦合”的思想。 概念簡介 １、表現(xiàn)層（ UI）：通俗講就是展現(xiàn)給用戶的界面，即用戶在使用一個系統(tǒng)的時候他的所見所得。 ２、業(yè)務(wù)邏輯層（ BLL）：針對具體問題的操作，也可以說是對數(shù)據(jù)層的操作，對數(shù)據(jù)業(yè)務(wù)邏輯處理。 ３、數(shù)據(jù)訪問層（ DAL）：該層所做事務(wù)直接操作數(shù)據(jù)庫，針對數(shù)據(jù)的增添、刪除、修改、更新 、查找等。 概述 在軟件體系架構(gòu)設(shè)計中，分層式結(jié)構(gòu)是最常見，也是最重要的一種結(jié)構(gòu)。 微軟 推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問層、業(yè)務(wù)邏輯層（又或成為領(lǐng)域?qū)樱?、表示層? 三層結(jié)構(gòu)原理： 3 個層次中，系統(tǒng)主要功能和業(yè)務(wù)邏輯都在業(yè)務(wù)邏輯層進行處理。 .Net 信息交流平臺系統(tǒng) 源碼及文檔下載地址： 所謂三層體系結(jié)構(gòu)，是在客戶端與數(shù)據(jù)庫之間加入了一個 “中間層 ”，也叫組件層。這里所說的三層體系，不是指物理上的三層，不是簡單地放置三臺機器就是三層體系結(jié)構(gòu)，也不僅僅有 B/S 應(yīng)用才是三層體系結(jié)構(gòu)，三層是指邏輯上的三層，即使這三個層放置到一臺機器上。 三層體系的應(yīng)用程序?qū)I(yè)務(wù)規(guī)則、數(shù)據(jù)訪問、合法性校驗等工作放到了中間層進行處理。通常情況下，客戶端不直接與數(shù)據(jù)庫進行交互，而是通過 COM/DCOM 通訊與中間層建立連接，再經(jīng)由中間層與數(shù)據(jù)庫進行交互。 表示層 位于最外層（最上層），離用戶最近。用于顯示數(shù)據(jù)和接收用戶輸入的數(shù)據(jù)，為用戶提供一種交互式操作的界面 。 業(yè)務(wù)邏輯層 業(yè)務(wù)邏輯層（ Business Logic Layer）無疑是系統(tǒng)架構(gòu)中體現(xiàn)核心價值的部分。它的關(guān)注點主要集中在業(yè)務(wù)規(guī)則的制定、業(yè)務(wù)流程的實現(xiàn)等與業(yè)務(wù)需求有關(guān)的系統(tǒng)設(shè)計，也即是說它是與系統(tǒng)所應(yīng)對的領(lǐng)域（ Domain）邏輯有關(guān)，很多時候，也將業(yè)務(wù)邏輯層稱為領(lǐng)域?qū)?。例?Martin Fowler 在《 Patterns of Enterprise Application Architecture》一書中，將整個架構(gòu)分為三個主要的層：表示層、領(lǐng)域?qū)雍蛿?shù)據(jù)源層。作為領(lǐng)域驅(qū)動設(shè)計的先驅(qū) Eric Evans，對業(yè)務(wù)邏輯層作了更細致地劃分，細分為應(yīng)用層與領(lǐng)域?qū)?，通過分層進一步將領(lǐng)域邏輯與領(lǐng)域邏輯的解決方案分離。 業(yè)務(wù)邏輯層在體系架構(gòu)中的位置很關(guān)鍵，它處于數(shù)據(jù)訪問層與表示層中間，起到了數(shù)據(jù)交換中承上啟下的作用。由于層是一種弱耦合結(jié)構(gòu)，層與層之間的依賴是向下的，底層對于上層而言是 “無知 ”的，改變上層的設(shè)計對于其調(diào)用的底層而言沒有任何影響。如果在分層設(shè)計時，遵循了面向接口設(shè)計的思想，那么這種向下的依賴也應(yīng)該是一種弱依賴關(guān)系。因而在不改變接口定義的前提下，理想的分層式架構(gòu)，應(yīng)該是一個支持可抽取 、可替換的 “抽屜 ”式架構(gòu)。正因為如此，業(yè)務(wù)邏輯層的設(shè)計對于一個支持可擴展的架構(gòu)尤為關(guān)鍵，因為它扮演了兩個不同的角色。對于數(shù)據(jù)訪問層而言，它是調(diào)用者；對于表示層而言，它卻是被調(diào)用者。依賴與被依賴的關(guān)系都糾結(jié)在業(yè)務(wù)邏輯層上，如何實現(xiàn)依賴關(guān)系的解耦，則是除了實現(xiàn)業(yè)務(wù)邏輯之外留給 設(shè)計師 的任務(wù)。 數(shù)據(jù)層 數(shù)據(jù)訪問層：有時候也稱為是持久層，其功能主要是負責(zé)數(shù)據(jù)庫的訪問，可 以訪問數(shù)據(jù)庫系統(tǒng)、二進制文件、文本文檔或是 XML 文檔。 簡單的說法就是實現(xiàn)對數(shù)據(jù)表的 Select， Insert， Update， Delete 的操作。如果要加入 ORM的元素，那么就會包括對象和數(shù)據(jù)表之間的 mapping，以及對象實體的持久化。 .Net 信息交流平臺系統(tǒng) 源碼及文檔下載地址： 優(yōu)點 開發(fā)人員可以只關(guān)注整個結(jié)構(gòu)中的其中某一層； 可以很容易的用新的實現(xiàn)來替換原有層次的實現(xiàn)； 可以降低層與層之間的依賴； 有利于標準化； 利于各層邏輯的復(fù)用。 缺點 降低了系統(tǒng)的性能。這是不言而喻的。如果不采用分層式結(jié)構(gòu)，很多業(yè)務(wù)可以直接造訪數(shù)據(jù)庫，以此獲取相應(yīng)的數(shù)據(jù)，如今卻必須通過中間層來完成。 有時會導(dǎo)致級聯(lián)的修改。這種修改尤其體現(xiàn)在自上而下的方向。如果在表示層中需要增加一個功能，為保證其設(shè)計符合分層式結(jié)構(gòu)，可能需要在相應(yīng)的業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層中都增加相應(yīng)的代碼。 規(guī)則 三層結(jié)構(gòu)的程序不是說把項目分成 DAL, BLL, WebUI 三個模塊就叫三層了 , 下面幾個問題在你的項目里面： 1. UILayer 里面只有少量 (或者沒有 )的 SQL 語句或者存儲過程調(diào)用 , 并且這些語句保證不會修改數(shù)據(jù) ? 2. 如果把 UILayer 拿掉 , 你的項目還能在 Interface/API 的層次上提供所有功能嗎 ? 3. 你的 DAL 可以移植到其他類似環(huán)境的項目嗎 ? 4. 三個模塊 , 可以分別運行于不同的服務(wù)器嗎 ? 如果不是所有答案都為 YES, 那么你的項目還不能算是嚴格意義上的三層程序 . 三層程序有一些需要約定遵守的規(guī)則： 1. 最關(guān)鍵的 , UI 層只能作為一個外殼 , 不能包含任何 BizLogic 的處理過程 2. 設(shè)計時應(yīng)該從 BLL 出發(fā) , 而不是 UI 出發(fā) . BLL 層在 API 上應(yīng)該實現(xiàn)所有 BizLogic, 以面向?qū)ο蟮姆绞? 3. 不管數(shù)據(jù)層是一個簡單的 SqlHelper 也好 , 還是帶有 Mapping 過的 Classes 也好 , 應(yīng)該在一定的抽象程度上做到系統(tǒng)無關(guān) 4. 不管使用 COM+(Enterprise Service), 還是 Remoting, 還是 WebService 之類的遠程對象技術(shù) , 不管部署的時候是不是真的分別部署到不同的服務(wù)器上 , 最起碼在設(shè)計的時候要做這樣的考慮 , 更遠的 , 還得考慮多臺服務(wù)器通過負載均衡作集群 所以考慮一個項目是不是應(yīng)該應(yīng)用三層 /多層設(shè)計時 , 先得考慮下是不是真的需要 ? 實際上大部分程序就開個 WebApplication 就足夠了 , 完全沒必要作的這么復(fù)雜 . 而多層結(jié)構(gòu) , 是用于解決真正復(fù)雜的項目需求的。 與 MVC 的區(qū)別 .Net 信息交流平臺系統(tǒng) 源碼及文檔下載地址： MVC（模型 Model視圖 View控制器 Controller）是一種設(shè)計模式，我們可以用它來創(chuàng)建在域?qū)ο蠛?UI 表示層對象之間的區(qū)分。 同樣是架構(gòu)級別的，相同的地方在于他們都有一個表現(xiàn)層，但是他們不同的地方在于其他的兩個層。 在三層架構(gòu)中沒有定義 Controller 的概念。這是我認為最不同的地方。而 MVC 也沒有把業(yè)務(wù)的邏輯訪問看成兩個層，這是采用三層架構(gòu)或 MVC 搭建程序最主要的區(qū)別。當(dāng)然了。在三層中也提到了 Model，但是三層架構(gòu)中 Model 的概念與 MVC 中 Model 的概念是不一樣的，“三層 ”中典型的 Model 層是以實體類構(gòu)成的，而 MVC 里，則是由業(yè)務(wù)邏輯與訪問數(shù)據(jù)組成的。 第三章 系統(tǒng)分析 實施醫(yī)院信息化建設(shè)以后，我們要通過互聯(lián)網(wǎng)和通訊系統(tǒng)選擇醫(yī)院、選擇醫(yī)生，進行網(wǎng)上掛號、預(yù)約就診，從而減少病人的排隊候診時間；通過屏幕顯示病人就診、檢查和取藥的時間，病人可以坐著等候；通過自動劃價收費系統(tǒng)和電子查詢系統(tǒng)，使病人對醫(yī)院收費放心等等。據(jù)了解，廣東衛(wèi)生信息化建設(shè)令人關(guān)注，目前正積極推行“電子病歷”醫(yī)院試點工作。以后老百姓到醫(yī)院看病，可望告別反復(fù)填資料、跑上跑下遞藥方、排隊等化驗單結(jié)果的奔波勞累，只需“ｅ網(wǎng)”輕松搞定。在具體的需求驅(qū)動下，我們采用計算機技術(shù)開發(fā)網(wǎng)上預(yù)約掛號系統(tǒng)。 系統(tǒng)功能描述 通過對用戶 需求的分析，本系統(tǒng)的功能主要包括兩塊，前臺用戶操作及后臺管理。操作流程如下圖： .Net 信息交流平臺系統(tǒng) 源碼及文檔下載地址： 管理員后臺 ER 圖 門診預(yù)約掛號 日期 用戶 時間 地址