這些天在做一個在線物聯的網站，同時也在往上查看了一些很好的網站架構，所以就根據自己的情況，指定了一種方案：
為了提交程序的：面向接口編程，高內聚、低耦合及其對擴充開發、對修改封閉的原則，對這次方案做簡單的總結：

我的整體思想三層技術：UI（表現層）、BLL（業務邏輯層）、DAL（數據庫訪問層）；

但是在我們的DAL層有很多種技術，提供我們去訪問數據庫，例如（ado.net、EF、NHibernate...）,所以這樣我們就要讓DAL層對外要有一個統一的接口，使得內部操作數據庫技術的變化不會涉及到BLL和UI層的代碼，同理BLL層也是一樣，他的修改不會牽連到UI層的展示，所以我把他們都分別分為兩部分一部分是接口、另一部分是具體的實現，并且實現去繼承這些接口，對外界訪問的就只是這些接口；并且每一層中都是針對多張表的增刪改查，因此抽象數來一張基類的增刪改查的類，這樣子類直接繼承就不用都有自己的實現了，

由于底層訪問數據庫我使用的是EF實體模型，所以為了控制EF上下文在線程內唯一，使用了一個簡單工廠，來獲取數據，而且為了能和EF那樣，只要拿到上下文對象，數據的所有操作方法及其數據對象也都在上下問對象中了，這種設計理念，在DAL層抽象出來了一個針對BLL層的DBSession類，它里面封裝了所有表的操作數據庫對象，及其數據庫的上下文對象，所以只要拿到這個對象后就能拿到，所有的數據表操作對象，及其他的增刪改查方法，但是要確保BLL層拿到的這個對象的唯一性，我有創建了一個針對獲取DBSession對象的工廠，由于EF對象對數據表的增刪改查有延遲性，并且每做一個增刪改查的方法都要像數據庫提交一次，所以我在這個類中又抽象出了一個方法，只有BLL層調用這個方法，才會對做的操作進行提交數據庫處理，仔細想一下，這個方法的確很有必要，因為，我們在對表進行增刪改查的時候，可能一個方法中，不僅僅對一張表的曾或者刪或者查，這樣只要統一調用一次保存方法，讓這些sql語句放在一個隊列中統一進行提交，統一訪問一次數據庫，這樣不僅提交了對數據庫的吞吐量，而且也減少了訪問次數，仔細像起來面向接口編程，著實是一項開天辟地的新格局，有了他直接承載了我們的多態，及其設計程序的原則也豐富多元化了

轉載于:https://www.cnblogs.com/One-dream-man/archive/2012/09/10/2679488.html

總結

以上是生活随笔為你收集整理的前些天做的一个物联网架构三层扩展的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。