開源項目閱讀

ERPCore應用系統快速開發平臺

---

 ErpCore是一套強大的雲計算ERP開發框架，集數據庫設計、軟件建模、模型自動生成、界面可視化設計、業務流可自定義、全自動生成用戶所需系統於一體。在此框架上擴展出全部行業的業務系統，它讓軟件工程師從「建模——寫代碼——測試」全部繁瑣重複的工做變爲全自動化生成，大大簡化了企業軟件的開發時間和成本；同時，使用該框架擴展的全部業務子系統可以無縫鏈接進行數據共享，這也是雲計算ERP的實現基礎，杜絕了傳統ERP的子系統信息孤島的弊端，真正實現無縫整合企業的全部資源進行管理。

   靈活的自定義對象功能解決了傳統ERP由軟件廠商定死業務規則的弊端，業務流規則將變成企業本身自定義，知足國內不一樣企業存在不一樣工做業務流、或者同一個企業不一樣時期的業務流變更狀況。

   功能描述：

一、自動建模

   框架內部帶有虛擬數據庫系統，用戶可在虛擬數據庫上建立表、字段、表間關聯，企業根據本身的具體業務需求構建合適的數據庫架構，即經過自動化實現銷售業務人員將能完成DBA的工做。業務流程將變成企業自定義。

二、自定義對象

   對應於虛擬數據庫上建立表、字段、表間關聯，用戶可自定義對象、對象屬性、對象關聯。奠基了能夠擴展出符合全部行業全部業務系統可能性。

三、窗體表單可視化設計

   經過拖拽拉的方式，業務人員便可建立軟件使用界面，把界面關聯起來便可實現不用編碼就能建立所需的業務系統。

四、全自動建立子系統

   管理員在後臺經過建立對象、建立窗體，並集成成一個子系統，普通使用人員就能使用子系統進行工做，不需額外開發工做。

五、雲計算提升效率

   系統可擴展出分佈式存儲計算，可集成多數據庫服務器，完美解決傳統ERP的單數據庫服務器的統計效率問題。

六、系統擴展及二次開發

   從框架的業務基類派生出更高一層的業務模型，企業的軟件開發人員快速開發出個性化功能的模型對象，知足不一樣企業的個性需求功能，並能與整個ERP系統無縫數據共享，真正把全部企業資源整合成一體。

 

HP-Socket通訊框架

---

 

HP-Socket 是一套通用的高性能 TCP/UDP/HTTP 通訊框架，包含服務端組件、客戶端組件和Agent組件，普遍適用於各類不一樣應用場景的 TCP/UDP/HTTP 通訊系統，提供 C/C++、C#、Delphi、E（易語言）、Java、Python 等編程語言接口。HP-Socket 對通訊層實現徹底封裝，應用程序沒必要關注通訊層的任何細節；HP-Socket 提供基於事件通知模型的 API 接口，能很是簡單高效地整合到新舊應用程序中。
    爲了讓使用者能方便快速地學習和使用 HP-Socket ，迅速掌握框架的設計思想和使用方法，特此精心製做了大量 Demo 示例（如：PUSH 模型示例、PULL 模型示例、PACK 模型示例、性能測試示例以及其它編程語言示例）。HP-Socket 目前運行在 Windows 平臺，未來會實現跨平臺支持。

    （加入技術支持羣）    

HP-Socket 的設計充分注重功能、通用型、易用性與伸縮性：

通用性

• HP-Socket 的惟一職責就是接收和發送字節流，不參與應用程序的協議解析等工做。
• HP-Socket 與應用程序經過接口進行交互，並徹底解耦。任何應用只要實現了HP-Socket的接口規範均可以無縫整合 HP-Socket。

易用性

• 易用性對全部通用框架都是相當重要的，若是太難用還不如本身重頭寫一個來得方便。所以，HP-Socket 的接口設計得很是簡單和統一。
• HP-Socket 徹底封裝了全部底層通訊細節，應用程序沒必要也不能干預底層通訊操做。通訊鏈接被抽象爲Connection ID，Connection ID 做爲鏈接的惟一標識提供給應用程序來處理不一樣的鏈接。
• HP-Socket 提供 PUSH / PULL / PACK 等接收模型， 應用程序能夠靈活選擇以手工方式、 半自動方式或全自動方式處理封解包， PULL / PACK 接收模型在下降封解包處理複雜度的同時能大大減小出錯概率。

高性能

• Client 組件：基於 Event Select 通訊模型，在單獨線程中執行通訊操做，避免與主線程或其餘線程相互干擾。每一個組件對象管理一個 Socket 鏈接。
• Server 組件：基於 IOCP 通訊模型，並結合緩存池、私有堆（Private Heap）等技術，支持超大規模鏈接，在高併發場景下實現高效內存管理。
• Agent 組件：對於代理服務器或中轉服務器等應用場景，服務器自身也做爲客戶端向其它服務器發起大規模鏈接，一個 Agent 組件對象同時可管理多個 Socket 鏈接；Agent 組件與 Server 組件採用相同的技術架構，能夠用做代理服務器或中轉服務器的客戶端部件。

伸縮性

    應用程序可以根據不一樣的容量要求、通訊規模和資源情況等現實場景調整 HP-Socket 的各項性能參數（如：工做線程的數量、緩存池的大小、發送模式和接收模式等），優化資源配置，在知足應用需求的同時沒必要過分浪費資源。

* Server 組件執行流程

 

* Agent 組件執行流程

 

* Client 組件執行流程

 

NFine技術介紹

---

NFine技術介紹：

一、前端技術

JS框架：jquery-2.1.一、Bootstrap.js、JQuery UI

CSS框架：Bootstrap v3.3.4（穩定是後臺，UI方面根據需求本身升級改造吧）。

客戶端驗證：jQuery Validation Plugin 1.9.0。

在線編輯器：ckeditor、simditor

上傳文件：Uploadify v3.2.1

動態頁籤：Jerichotab（本身改造）

數據表格：jqGrid、Bootstrap Talbe

對話框：layer-v2.3

下拉選擇框：jQuery Select2

樹結構控件：jQuery zTree、jQuery wdtree

頁面佈局：jquery.layout.js 1.4.4

圖表插件：echarts、highcharts

日期控件： My97DatePicker

二、後端技術

核心框架：ASP.NET MVC五、WEB API

持久層框架：EntityFramework 6.0

定時計劃任務：Quartz.Net組件

安全支持：過濾器、Sql注入、請求僞造

服務端驗證：實體模型驗證、本身封裝Validator

緩存框架：微軟自帶Cache、Redis

日誌管理：Log4net、登陸日誌、操做日誌

工具類：NPOI、Newtonsoft.Json、驗證碼、豐富公共相似

 

OSGi.NET應用程序擴展

---

 

OSGi.NET 詳細介紹

這是實現的一套基於OSGi規範的C#基礎框架-OSGi.NET，而且用Go語言初步實現了插件的管理平臺-插件倉庫。在幾個中小型項目中有所應用（Winform、WPF），主要能夠解決多人協做的開發規範與插件的管理問題。

更多說明: http://www.diginfo.me/osgi-net-implement

簡介：

OSGi.NET框架是一個參照了OSGi規範的模塊化管理框架。框架爲應用程序擴展（組件（bundle））提供了一個標準環境。整個框架能夠劃分爲一些層次：

1. 運行環境
2. 模塊（Bundle）
3. 生命週期管理
4. 服務註冊
5. 擴展點支持

目前OSGi.NET具備以下特點：

1. 組件的可插拔性：組件可根據業務須要在運行時進行裝載、卸載操做
2. 組件的動態更新：組件在運行時可更新替換當前版本
3. 組件的版本隔離：不一樣組件引用相同產品的不一樣版本程序集能夠版本隔離
4. 組件完整的生命週期：包括已安裝、已裝載、已激活、啓動中、中止中、已卸載
5. 組件的加載順序：組件加載根據業務要求可設置加載級別來控制加載次序
6. 組件的通訊支持：組件間經過面向服務的編程模型來達到組件間通訊、調用的目的
7. 組件的擴展支持：組件提供了擴展點及其擴展來知足某個組件的擴展性支持

啓動一個OSGi.NET應用程序僅須要以下代碼

using System;

 

using OSGi.NET.Core.Root;

 

namespace ConsoleDemo

{

    class Program

    {

        static void Main(string[] args)

        {

            //建立框架工廠

            var frameworkFactory = new FrameworkFactory();

            //建立框架內核

            var framework = frameworkFactory.CreateFramework();

            //初始化框架

            framework.Init();

            //啓動框架

            framework.Start();

 

            Console.ReadLine();

        }

    }

}

建立一個OSGi.NET項目須要：

1. 引用框架內核程序集OSGi.NET.dll
2. 添加框架內核配置文件OSGi.NET.properties
3. 如須要日誌支持，添加log4net.config文件及log4net.dll程序集引用

OSGi.NET項目的默認文件目錄結構以下
/程序目錄
/程序目錄/Bundles/
/程序目錄/Bundles/模塊A/
/程序目錄/Bundles/模塊A/Manifest.xml
/程序目錄/Bundles/模塊A/模塊A.dll
/程序目錄/Bundles/模塊A/Libs/
/程序目錄/Bundles/模塊A/Libs/* .dll
/程序目錄/Bundles/模塊B/
/程序目錄/Bundles/模塊C/
/程序目錄/Libs/(可選)
/程序目錄/OSGi.NET.properties
注：
程序目錄中的Libs文件夾存放個Bundles的共享程序集(也可經過在配置文件中配置共享清單)，如接口契約、公共第三方類庫等。
模塊A中的Libs文件夾存放其私有程序集。
Manifest.xml做爲程序清單文件對模塊進行自描述。
OSGi.NET.properties爲框架內核配置文件

關於加載次序：
因爲業務需求，各模塊存在依賴關係的可能，因此模塊加載也會有加載順序的要求，此時能夠經過清單文件中Manifest.xml，Bundle節點的StartLevel屬性對其加載次序進行設置。數值越小，加載越前。 

關於Bundle引用程序集搜索原則：

1. 根據加載的Bundle引用程序集，依據程序集名稱+版本號匹配原則，優先從[/程序目錄/Libs/]目錄或共享清單中搜索。
2. 如第一步無匹配，則根據程序集名稱從[/程序目錄/Bundles/模塊A/Libs/*.dll]目錄搜索，並將搜索到的程序集對應版本關聯Bundle。
3. 各Bundle下Libs目錄程序集在加載中作了Bundle間的隔離，確保不一樣的Bundle引用的程序集間不會形成影響。即：如存在共享程序集請放置[/程序目錄/Libs/]目錄或在共享清單配置。

 

SSIO框架介紹

---

 

ServerSuperIO 簡稱 SSIO ，是一個 C# 跨平臺物聯網通信框架。

一.SSIO的特色

1. 輕型高性能通訊框架，適用於多種應用場，輪詢模式、自控模式、併發模式和單例模式。
2. 設備驅動、IO通道、控制模式場景協調統一。
3. 設備驅動內軒命令驅動器、命令緩存器、自定義參數和實時數據元素。
4. 框架平臺支持按設備命令優先級別進行調度，保證高級別命令及時發送。
5. 一個設備驅動同時支持串口和網絡兩種通信方式，能夠監視IO通道數據。
6. 一個設備驅動，在網絡通信時能夠支持TCP Server和TCP Client兩種工做模式。
7. 內置顯示視圖接口，知足不一樣顯示需求。
8. 內置服務組件接口，能夠自定義完成OPC服務、4-20mA輸出、LED大屏顯示、短信服務、以及多功能網關服務。
9. 能夠建立多服務實例，完成不一樣業務的拆分。

10. 支持跨平臺部署，能夠運行在Linux和Windows系統。

二.SSIO概述

   SSIO通訊框架的設計思想是在SuperIO（SIO）基礎上發展而來，並無高大上的技術，主要是工做經驗的積累，適合於不一樣應用場景的物聯網的數據 採集與交互。SSIO和SIO並非簡單的對IO高性能的操做，而是設備驅動、IO通道、控制模式和實際硬件設備之間的協調機制，各方面之間無縫銜接和運 行，也是爲了解決現實工做和應用場景的一些痛點。

  軟硬件之間的數據交互，而且面臨着複雜的現場環境：

（1）複雜的、多樣的通信協議。有標準的協議，例如：Modbus等，也有不少根據標準協議修改的協議格式、以及自定義協議格式，而且千差萬別。對於很差的軟件架構，疲於應對，增長設備或協議要對整個軟件進行梳理，每每在此過程當中出現新的問題或BUG。

（2）針對不一樣用戶對軟件界面或功能的要求有很大不一樣，使之知足不一樣用戶的顯示要求，能夠自定義數據顯示界面。那麼就須要提供顯示視圖接口，與設備驅動進行交互。

（3）既然現場設備的數據被採集上來，那麼就須要對其進行處理，不只僅是保存、查詢、報表等，還有：數據轉發、數據輸出（OPC、模擬量、大屏等）等。那麼就須要提供服務性的接口，與設備驅動進行交互。

（4）通信鏈路的多種性，對於同一個設備可能要支持RS232/RS485/RS42二、RJ4五、3G/4G等通信方式，因此對於一個設備要對應多種通信方式（串口和網絡），也給咱們的開發形成很大的障礙。

（5）設備驅動、IO通道和實際的現場硬件終端之間鏈路複雜，有可能：一個設備驅動對應一個IO通道、一個設備驅動對應多個IO通道、多個設備驅動對應一個IO通道等狀況。

（6）既然設備與服務端進行數據交互，那麼就應該對設備的通信狀態、IO狀態、以及設備自己的狀態進行監控，這樣設備才處於可維護狀態。

（7）軟件各版本、以及軟件與硬件之間的兼容性不好，管理起來錯綜複雜。在框架平臺穩定的狀況下，只須要更新設備驅動。

   爲了解決以上諸多問題，開發一個軟件框架，支持二次開發。在不對軟件框架改動的狀況下，可以很方便的接入設備、維護設備、集成設備、處理設備業務數據等。軟件框架相對穩定，把容易變化的部分進行靈活設計。

三.控制模式

（1）輪詢模式：當串口和網絡通信時均可以使用這種控制模式。當有多個設備 鏈接到通信平臺時，通信平臺會輪詢調度設備進行通信任務。某一時刻只能有一個設備發送請求命令、等待接收返回數據，這個設備完成發送、接收（若是遇到超時 狀況，則自動返回）後，下一個設備才進行通信任務，依次輪詢設備。以下圖：

 

（2）併發模式：只有網絡通信時可使用這種控制模式。併發通信模式是集中 發送全部設備的請求指令，框架是採用循環同步方式發送請求命令。還有進一步提升的機會，採用並行異步方式集中發送請求命令。硬件設備接收到指令後進行校 驗，校驗成功後返回對應指令的數據，通信平臺異步監聽到數據信息後，進行接收操做，而後再進行數據的分發、處理等。以下圖：

 

（3）自控模式：只有網絡通信時可使用這種控制模式。自控通信模式與併發 通信模式相似，區別在於發送指令操做交給設備驅動自己進行控制，或者說交給二次開發者，二次開發者能夠經過時鐘定時用事件驅動的方式發送指令數據。硬件設 備接收到指令後進行校驗，校驗成功後返回對應指令的數據，通信平臺異步監聽到數據信息後，進行接收操做，而後再進行數據的分發、處理等。

   自控通信模式能夠爲二次開發者提供精確的定時請求實時數據機制，使通信機制更靈活、自主，若是多個設備驅動使用同一個IO通道的話，時間控制會有誤差。以下圖：

 

（4）單例模式：只有網絡通信時可使用這種控制模式。在一個服務實例內只 能有一個設備驅動，至關於一個設備驅動對應着N多個硬件設備終端。更適合通信的數據協議有固定的標準，以命令關鍵字處理不一樣的數據。適用於高併發的硬件終 端設備主動上傳數據，服務器端根據數據信息進行處理和返回相應的數據。以下圖：

 

 

四.跨平臺Windows和Linux

（1）Windows運行效果

 

（2）Linux運行效果

 

 Office讀寫NPOI

---

NPOI 是 POI 項目的 .NET 版本。POI是一個開源的Java讀寫Excel、WORD等微軟OLE2組件文檔的項目。

使用 NPOI 你就能夠在沒有安裝 Office 或者相應環境的機器上對 WORD/EXCEL 文檔進行讀寫。