主持人 > 博客 > 管理 > 平台「1C：企業」－幕後有什麼？

平台「1C：企業」－幕後有什麼？

嘿哈布爾！
在這篇文章中，我們將開始講述它的內部運作原理 平台“1C：企業8” 以及其開發中使用了哪些技術。

平台「1C：企業」－幕後有什麼？

為什麼我們認為這很有趣？ 首先，因為 1C:Enterprise 8 平台是一個大型（超過 10 萬行程式碼）應用程序，採用 C++（客戶端、伺服器等）、JavaScript（Web 用戶端），以及最近的 Java的。 大型專案可能會很有趣，至少因為它們的規模，因為在小型程式碼庫中看不見的問題在此類專案中全面出現。 其次，《1C:Enterprise》是一個可複製的、「盒裝」的產品，關於哈布雷的這類開發的文章很少。 了解其他團隊和公司的生活也總是很有趣。

那麼就讓我們開始吧。 在本文中，我們將概述該平台中使用的一些技術並概述總體情況，而不會深入研究實現。 事實上，對於許多機制來說，詳細的故事需要一篇單獨的文章，對於某些機制來說，需要一整本書！
首先，有必要確定基本的事情 - 1C:Enterprise 平台是什麼以及它由哪些元件組成。 這個問題的答案並不那麼簡單，因為術語「平台」（為簡潔起見，我們這樣稱呼它）指的是開發業務應用程式、執行時間環境和管理工具的手段。 大致可以區分出以下幾個組成部分：

  • 伺服器叢集
  • 「瘦」客戶端能夠透過 http 及其自己的二進位協定連接到伺服器
  • 用於在兩層架構中工作的客戶端，資料庫位於硬碟或網路資料夾上
  • 網路客戶端
  • 應用伺服器管理工具
  • 開發環境（稱為配置器）
  • iOS、Android 和 Windows Phone（行動平台 1C）的執行環境

除 Web 用戶端外，所有這些部分都是用 C++ 編寫的。 此外，最近也公佈了 新一代配置器，用 Java 編寫。

本機應用程式

C++03 用於開發本機應用程式。 對於 Windows，使用 Microsoft Visual C++ 12（與 Windows XP 相容的設定檔）作為編譯器，對於 Linux 和 Android，使用 gcc 4.8，對於 iOS，使用 clang 5.0。 所有作業系統和編譯器使用的標準函式庫都是相同的 - STLPort。 該解決方案降低了 STL 實現特定錯誤的可能性。 我們目前計劃遷移到 CLang 附帶的 STL 實現，因為 STLPort 已停產並且與 gcc 的 C++11 啟用模式不相容。
伺服器的程式碼庫有 99% 的通用性，客戶端的程式碼庫有 95% 的通用性。 此外，即使是行動平台也使用與「大」平台相同的 C++ 程式碼，儘管統一的比例要低一些。
與大多數 C++ 使用者一樣，我們並不聲稱使用該語言及其程式庫的 100% 功能。 因此，我們實際上不使用 Boost，語言功能之一是動態類型轉換。 同時，我們積極利用：

  • STL（特別是字串、容器和演算法）
  • 多重繼承，包括。 多重實現繼承
  • 模板
  • 例外
  • 智慧指標（自訂實作）

透過使用介面的多重繼承（完全抽象類別），組件模型成為可能，這將在下面討論。

組件

為了確保模組化，所有功能都分為元件，這些元件是動態函式庫（Windows 為*.dll，Linux 為*.so）。 總共有一百五十多個組件；以下是其中一些組件的說明：

後端
包含平台元資料引擎

帳戶
應用程式開發人員用來建立會計記錄的物件（會計科目表和會計登記簿）

BSL
嵌入式語言執行引擎

核彈
記憶體分配器的自訂實現

德邦8
文件資料庫引擎。 一個基於ISAM的簡單檔案伺服器資料庫引擎，其中還包括一個簡單的SQL處理器

資料庫
包含用於實現 Windows 使用者介面的基底類別和函數 - 視窗類別、GDI 存取等。

從幾個角度來看，劃分為多個組件是有用的：

  • 分離促進更好的設計，特別是更好的程式碼隔離
  • 您可以透過一組組件靈活地組裝不同的交付選項：
    • 例如，瘦客戶端安裝將包含 wbase，但不會有後端
    • 但在wbase伺服器上，相反，不會
    • 兩個選項當然都包含 nuke 和 bsl

程式啟動時會載入此啟動選項所需的所有元件。 這對於註冊 SCOM 類別尤其是必要的，這將在下面討論。

司康

對於較低的分解，使用 SCOM 系統，這是一個在思想上與 ATL 類似的函式庫。 對於那些沒有使用過 ATL 的人，我們簡單列出了主要功能和特性。
對於專門設計的 SCOM 類別：

  • 提供工廠方法，讓您從僅知道其名稱的另一個元件建立類別（而不透露實作）
  • 提供引用計數智慧指標基礎設施。 SCOM類別的生命週期不需要手動監控
  • 允許你找出一個物件是否實現了特定的接口，並自動將指向該物件的指針轉換為指向該接口的指針
  • 建立一個始終可以透過 get_service 方法等存取的服務物件。

例如，您可以在 json.dll 元件中描述用於讀取 JSON 的類別（例如 JSONStreamReader）。
類別和實例可以從其他元件建立；它們需要在 SCOM 機器中註冊：

SCOM_CLASS_ENTRY(JSONStreamReader)

該巨集將描述一個特殊的靜態記錄器類，當元件載入到記憶體時將呼叫該類的建構函數。
之後，您可以在另一個元件中建立它的實例：

IJSONStreamReaderPtr jsonReader = create_instance<IJSONStreamReader>(SCOM_CLSIDOF(JSONStreamReader));

為了支援服務，SCOM 提供了一個額外的、相當複雜的基礎設施。 它的核心是 SCOM 進程的概念，它充當運行服務的容器（即扮演服務定位器的角色），並且還包含對本地化資源的綁定。 SCOM 行程與作業系統執行緒相關聯。 因此，在應用程式內您可以接收以下服務：

SCOM_Process* process = core::current_process();
if (process)
         return get_service<IMyService>(process);

此外，透過切換與執行緒相關的邏輯 (SCOM) 進程，您可以獲得從資訊空間的角度來看實際上獨立的應用程序，並在同一執行緒中運行。 這就是我們的瘦客戶端使用檔案資料庫的方式 - 在一個作業系統進程內有兩個 SCOM 進程，一個與客戶端關聯，第二個與伺服器關聯。 這種方法使我們能夠統一編寫可在本機檔案資料庫和「真實」客戶端伺服器版本中運行的程式碼。 這種一致性的代價是開銷，但實踐表明這是值得的。

基於SCOM元件模型，實作了1C：Enterprise的業務邏輯和介面部分。

用戶界面

順便說一下接口。 我們不使用標準 Windows 控制項；我們的控制項直接在 Windows API 上實作。 對於 Linux 版本，已經創建了一個透過 wxWidgets 庫工作的層。
控制項庫不依賴 1C:Enterprise 的其他部分，並且由我們在其他幾個小型內部實用程式中使用。

在 1C:Enterprise 的多年發展中，控制項的外觀發生了變化，但原理上的重大變化只發生過一次，即 2009 年，隨著版本 8.2 的發布和「託管表單」的出現。 除了改變外觀之外，表單佈局的原則也發生了根本性的改變——拒絕元素的逐像素定位，轉而支持元素的流動佈局。 此外，在新模型中，控制不直接與領域物件一起工作，而是與特殊的DTO（數據傳輸對象).
這些變更使得建立複製 JavaScript 控制項的 C++ 邏輯的 1C:Enterprise Web 用戶端成為可能。 我們嘗試保持瘦客戶端和 Web 用戶端之間的功能等效性。 如果這是不可能的，例如由於可用的 JavaScript API 的限制（例如，處理文件的能力非常有限），我們通常使用用 C++ 編寫的瀏覽器擴充功能來實現必要的功能。 我們目前支援 Internet Explorer 和 Microsoft Edge (Windows)、Google Chrome (Windows)、Firefox（Windows 和 Linux）和 Safari (MacOS)。

此外，託管表單技術也用於為 1C 平台上的行動應用程式建立介面。 在行動裝置上，控制項的渲染是使用作業系統原生的技術來實現的，但對於表單佈局邏輯和介面回應，則使用與「大型」1C：企業平台中相同的程式碼。

平台「1C：企業」－幕後有什麼？
Linux作業系統上的1C介面

平台「1C：企業」－幕後有什麼？
行動裝置上的1C接口

其他平台1C接口 平台「1C：企業」－幕後有什麼？
Windows作業系統上的1C介面

平台「1C：企業」－幕後有什麼？
介面 1C - Web 用戶端

開源

雖然我們不使用 Windows 下 C++ 開發人員的標準函式庫（MFC、WinAPI 中的控制項），但我們並不會自己編寫所有元件。 圖書館已經提過 小部件，我們也使用：

這樣的例子還在繼續。
此外，我們使用高度修改的版本 谷歌測試 и 谷歌模擬 開發單元測試時。
這些庫需要進行調整才能與 SCOM 元件組織模型相容。
1C 的流行使得該平台成為對其所使用的庫進行實力測試的絕佳場所。 即使是最很少使用的程式碼區域，各種使用者和場景也會很快發現錯誤。 我們自己更正它們，並嘗試將它們回饋給庫作者。 互動體驗變得非常不同。
開發人員 捲曲 и 利貝特潘 快速回應拉取請求，但是補丁，例如， OpenSSL的 我們從未設法把它歸還。

結論

在文章中我們談到了1C開發的幾個主要面向：企業平台。 在本文的有限範圍內，我們只觸及了一些我們認為有趣的面向。
可以找到各種平台機制的一般描述 這裡.
您在以後的文章中會對哪些主題感興趣？

1C行動平台是如何實現的？
Web客戶端的內部結構描述？
或者您可能對為新版本選擇功能、開發和測試的過程感興趣？

寫在評論裡吧！

來源： www.habr.com

添加評論