自動(dòng)化軟件解耦實(shí)踐)
1. 項(xiàng)目概述為什么工業(yè)自動(dòng)化軟件需要一套自己的依賴注入方案這幾年一直在做工業(yè)自動(dòng)化上位機(jī)軟件從早期的簡單工控界面到后來的整線調(diào)度系統(tǒng)項(xiàng)目越做越大代碼結(jié)構(gòu)也從一開始的“能跑就行”變成了后來的“改一個(gè)地方崩三個(gè)地方”。真正讓我下定決心重構(gòu)依賴關(guān)系的是一次設(shè)備層驅(qū)動(dòng)的替換——因?yàn)楣?yīng)商換了通信協(xié)議我需要把底層串口通信類換成TCP版本結(jié)果牽扯到界面層、業(yè)務(wù)層、數(shù)據(jù)處理層十幾個(gè)文件都要跟著改光是排查引用關(guān)系就花了整整兩天。那時(shí)候我意識到工業(yè)自動(dòng)化軟件雖然不像互聯(lián)網(wǎng)系統(tǒng)那樣追求極致的并發(fā)和彈性但它的設(shè)備類型多、通信協(xié)議雜、現(xiàn)場需求變化快如果沒有一套合理的解耦機(jī)制維護(hù)成本會隨著項(xiàng)目迭代指數(shù)級上升。簡單來說依賴注入Dependency Injection簡稱DI和IoC容器Inversion of Control控制反轉(zhuǎn)容器解決的核心問題就是對象不應(yīng)該自己 new 自己依賴的東西而應(yīng)該由外部統(tǒng)一創(chuàng)建并“注入”進(jìn)來。這個(gè)思想在很多互聯(lián)網(wǎng)項(xiàng)目中已經(jīng)是非常基礎(chǔ)的實(shí)踐了但在工業(yè)自動(dòng)化領(lǐng)域尤其是很多老牌工控軟件團(tuán)隊(duì)里還停留在“工具類全部static、設(shè)備驅(qū)動(dòng)寫死在構(gòu)造函數(shù)里、換一個(gè)硬件型號就要改源碼重新編譯”的階段。我寫這套基于 Ninject 的可配置式依賴注入框架目標(biāo)很明確——讓工業(yè)自動(dòng)化軟件的模塊像樂高積木一樣可以在不修改代碼的前提下通過配置文件調(diào)整組裝方式適應(yīng)不同產(chǎn)線、不同設(shè)備、不同通信協(xié)議的需求。這套方案適合誰參考如果你正在做 .NET 平臺的工控上位機(jī)、SCADA系統(tǒng)、設(shè)備調(diào)度軟件或者任何涉及多種硬件設(shè)備接入、通信協(xié)議頻繁變更的桌面應(yīng)用這篇文章里關(guān)于依賴注入容器選型、模塊化裝配、配置驅(qū)動(dòng)實(shí)例化、作用域管理的思路都可以直接借鑒。我會把完整的設(shè)計(jì)思路、核心代碼實(shí)現(xiàn)、以及我在實(shí)際項(xiàng)目中踩過的坑都寫出來盡量做到拿來即用。2. 方案選型為什么是 Ninject 而不是其他 IoC 容器在定下使用 Ninject 之前我其實(shí)對比過 .NET 生態(tài)里幾個(gè)主流的依賴注入容器包括微軟官方推薦的 Unity、性能和功能都很全面的 Autofac以及輕量級的 DryIoc。每個(gè)容器都有自己的生態(tài)位但在工業(yè)自動(dòng)化這個(gè)特定場景下Ninject 有幾個(gè)非常突出的優(yōu)勢值得展開說一下。首先Ninject 的綁定語法在“條件式綁定”和“約定式綁定”上非常靈活。工業(yè)自動(dòng)化軟件里最典型的場景就是“同一接口有多個(gè)實(shí)現(xiàn)”比如我定義一個(gè)IDeviceDriver接口可能有西門子PLC驅(qū)動(dòng)、Modbus驅(qū)動(dòng)、三菱驅(qū)動(dòng)等多個(gè)實(shí)現(xiàn)類。在運(yùn)行時(shí)到底該注入哪個(gè)實(shí)現(xiàn)取決于現(xiàn)場的配置文件或者設(shè)備類型。Ninject 支持通過When()條件來動(dòng)態(tài)選擇綁定也支持通過約定Convention批量掃描程序集自動(dòng)注冊這兩點(diǎn)正好命中工控軟件的痛點(diǎn)。其次Ninject 的kernel 是可擴(kuò)展的。它的核心設(shè)計(jì)基于“組件”模式你可以在不修改容器源碼的情況下通過實(shí)現(xiàn)IResolveExtension或自定義IProvider來擴(kuò)展實(shí)例創(chuàng)建的策略。這一點(diǎn)對于工業(yè)現(xiàn)場那種“某些設(shè)備驅(qū)動(dòng)必須保持單例某些通信對象必須每次新建”的復(fù)雜生命周期需求來說非常友好。我選擇 Ninject 還有一個(gè)很重要的現(xiàn)實(shí)原因——它在 WPF/WinForms 這類桌面技術(shù)棧里集成非常順滑。工業(yè)自動(dòng)化軟件絕大多數(shù)是桌面應(yīng)用這跟互聯(lián)網(wǎng)項(xiàng)目完全不同而 Ninject 對INotifyPropertyChanged、Prism這類 MVVM 框架的適配做得比較成熟。后面我會專門用一節(jié)講 Ninject 和 Prism 的聯(lián)動(dòng)這是我們這類項(xiàng)目繞不開的話題。當(dāng)然Ninject 也有它的問題最明顯的是性能比 Autofac 略遜一籌。但說實(shí)話在工控上位機(jī)這種場景里對象創(chuàng)建的頻率和互聯(lián)網(wǎng)高并發(fā)根本不在一個(gè)量級。一個(gè)界面啟動(dòng)時(shí)創(chuàng)建幾十個(gè)對象就算每個(gè)多花零點(diǎn)幾毫秒用戶也完全感知不到。我判斷一個(gè)技術(shù)選型是否合適核心標(biāo)準(zhǔn)是“在滿足需求的前提下最小化團(tuán)隊(duì)理解和維護(hù)成本”Ninject 恰好就是這個(gè)平衡點(diǎn)。3. 框架總體結(jié)構(gòu)從設(shè)備驅(qū)動(dòng)到界面層的完整解耦設(shè)計(jì)這一節(jié)是整個(gè)方案的主干。我要設(shè)計(jì)的不僅僅是用 Ninject 做幾個(gè)類的注入而是一套完整的、可配置的架構(gòu)讓工業(yè)自動(dòng)化軟件的各個(gè)層次都建立起清晰的依賴邊界。在設(shè)計(jì)這套框架之前我梳理了工業(yè)自動(dòng)化軟件的幾個(gè)典型層次界面層人機(jī)交互、業(yè)務(wù)流程層工藝邏輯、生產(chǎn)流程、設(shè)備抽象層PLC、傳感器、機(jī)器人、視覺系統(tǒng)等硬件封裝、通信層串口、TCP/IP、Profinet、EtherCAT等、數(shù)據(jù)處理層數(shù)據(jù)采集、存儲、報(bào)表。傳統(tǒng)寫法里這些層次之間經(jīng)常是直接引用、直接 new 的關(guān)系比如界面層里就寫著var driver new SiemensPLCDriver(192.168.0.1)。這樣的代碼在單一設(shè)備、單一協(xié)議的小項(xiàng)目里沒有大問題但一旦項(xiàng)目變成“支持5種PLC、3種機(jī)器人、2種視覺系統(tǒng)”的整線方案這種強(qiáng)耦合關(guān)系就會變成災(zāi)難。我的設(shè)計(jì)思路是定義清晰的接口契約所有依賴都面向接口編程對象之間的組裝關(guān)系全部交給 Ioc 容器管理。第一版框架我規(guī)劃了三個(gè)核心程序集Platform.Abstractions抽象層定義接口和基礎(chǔ)實(shí)體、Platform.DeviceDrivers設(shè)備驅(qū)動(dòng)實(shí)現(xiàn)、Platform.Host宿主程序負(fù)責(zé)裝配容器、加載配置、啟動(dòng)流程。拿設(shè)備驅(qū)動(dòng)來舉例這是工業(yè)軟件里最容易變也最關(guān)鍵的部分。我定義了一個(gè)IDeviceDriver接口它包含Connect()、Disconnect()、ReadData(string tag)、WriteData(string tag, object value)等基礎(chǔ)方法以及DeviceStatus狀態(tài)屬性。不同廠商的 PLC 通信協(xié)議完全不一樣但只要它們都實(shí)現(xiàn)了這個(gè)接口上層業(yè)務(wù)代碼就完全不需要關(guān)心底層協(xié)議細(xì)節(jié)。業(yè)務(wù)層只要寫“從運(yùn)維水站讀取溫度值”而不需要知道這個(gè)溫度值是通過 S7 協(xié)議還是 Modbus TCP 讀上來的。在設(shè)計(jì)這套框架時(shí)我還額外抽象了一層“設(shè)備工廠”的概念。為什么需要設(shè)備工廠因?yàn)楣た噩F(xiàn)場存在大量“動(dòng)態(tài)創(chuàng)建設(shè)備實(shí)例”的場景。比如一個(gè)配置系統(tǒng)里用戶根據(jù)產(chǎn)線實(shí)際布局在配置界面添加了5臺PLC和3臺機(jī)器人程序啟動(dòng)時(shí)需要根據(jù)配置信息實(shí)例化8個(gè)驅(qū)動(dòng)對象而且每臺設(shè)備的參數(shù)IP地址、端口、站號各不相同。這時(shí)候如果還是用構(gòu)造函數(shù)直接注入你會發(fā)現(xiàn)沒法注入——因?yàn)槟愀静恢绬?dòng)時(shí)需要多少個(gè)實(shí)例。我的方案是定義一個(gè)IDeviceDriverFactory它接收配置項(xiàng)DeviceConfig作為參數(shù)根據(jù)配置里的DeviceType字段用 Ninject 的 Kernel 動(dòng)態(tài)獲取對應(yīng)類型的實(shí)例然后初始化參數(shù)后返回。這樣一來設(shè)備數(shù)量、類型、參數(shù)全部配置化代碼里只維護(hù)“如何創(chuàng)建”的規(guī)則而不關(guān)心“創(chuàng)建誰”和“創(chuàng)建幾個(gè)”。這套結(jié)構(gòu)的好處在實(shí)際項(xiàng)目中體現(xiàn)得非常直接。我們曾經(jīng)有一個(gè)項(xiàng)目前期調(diào)研時(shí)客戶說用的是西門子 S7-1200 PLC代碼寫好后到現(xiàn)場實(shí)施時(shí)客戶突然說有一臺設(shè)備換成了三菱FX5U。放在以前這意味著一大波代碼修改和重新編譯部署。但在新框架下我只需要在配置文件的設(shè)備列表里加一條新記錄指定設(shè)備類型為MitsubishiDriver填上 IP 和端口號重啟程序就完事了——業(yè)務(wù)層代碼一行都不用動(dòng)。這就是解耦帶來的直接收益。4. 核心實(shí)現(xiàn)詳解Ninject 模塊化配置與裝配容器設(shè)計(jì)4.1 統(tǒng)一定義 Ninject 模塊Ninject 里有“模塊Module”的概念你可以把一組相關(guān)的綁定封裝到一個(gè)模塊里然后統(tǒng)一加載。在工業(yè)自動(dòng)化框架里我按“功能域”來劃分模塊每個(gè)功能域?qū)?yīng)一個(gè) Ninject 模塊設(shè)備驅(qū)動(dòng)注冊到一個(gè)驅(qū)動(dòng)模塊通信層注冊到通信模塊業(yè)務(wù)服務(wù)注冊到服務(wù)模塊界面層需要的 ViewModel 注冊到界面模塊。每個(gè)模塊類繼承NinjectModule在Load()方法里定義綁定關(guān)系。下面是我在項(xiàng)目中實(shí)際使用的模塊定義代碼。這里我定義一個(gè)統(tǒng)一的接口IDependencyModule方便后續(xù)用反射統(tǒng)一掃描和加載模塊。// Platform.Abstractions public interface IDependencyModule { void LoadBindings(IKernel kernel); } // Platform.DeviceDrivers public class DeviceDriverModule : IDependencyModule { public void LoadBindings(IKernel kernel) { // 默認(rèn)綁定沒有指定具體類型時(shí)使用通用驅(qū)動(dòng) kernel.BindIDeviceDriver().ToGenericDriver(); // 命名綁定按設(shè)備類型區(qū)分不同廠商的驅(qū)動(dòng)實(shí)現(xiàn) kernel.BindIDeviceDriver().ToSiemensS7Driver().Named(Siemens); kernel.BindIDeviceDriver().ToModbusTcpDriver().Named(Modbus); kernel.BindIDeviceDriver().ToMitsubishiDriver().Named(Mitsubishi); // 設(shè)備工廠單例工廠本身無狀態(tài)整個(gè)系統(tǒng)只需要一個(gè)實(shí)例 kernel.BindIDeviceDriverFactory().ToDeviceDriverFactory().InSingletonScope(); } }這里有個(gè)非常重要的設(shè)計(jì)——命名綁定。Ninject 允許你給同一個(gè)接口的不同實(shí)現(xiàn)綁定不同的名字然后在解析時(shí)通過名字精確獲取。在很多場景里我們可以提前知道設(shè)備的類型比如從配置文件的DeviceType字段讀取字符串值然后用這個(gè)名字去容器里找對應(yīng)的實(shí)現(xiàn)。這個(gè)方法比寫一堆if (type Siemens) return new SiemensDriver();的硬編碼優(yōu)雅得多而且新增一種設(shè)備驅(qū)動(dòng)時(shí)只需要增加一個(gè)新的綁定和一個(gè)實(shí)現(xiàn)類不需要改動(dòng)工廠方法。4.2 約定式掃描自動(dòng)注冊除了手動(dòng)綁定Ninject 還支持約定式綁定Convention Binding。你可以讓它自動(dòng)掃描某個(gè)程序集中的所有類型找到實(shí)現(xiàn)某類接口的類型自動(dòng)建立綁定關(guān)系。這在工業(yè)軟件里的價(jià)值非常大——因?yàn)轵?qū)動(dòng)數(shù)量會持續(xù)增長每增加一個(gè)新設(shè)備的驅(qū)動(dòng)如果都要手動(dòng)寫一行Bind代碼雖然不累但容易漏。我用Ninject.Extensions.Conventions擴(kuò)展來實(shí)現(xiàn)自動(dòng)注冊。核心邏輯是掃描所有以Driver結(jié)尾的類型找出它們實(shí)現(xiàn)的IDeviceDriver接口以類名的前綴作為綁定名自動(dòng)注冊。當(dāng)然自動(dòng)注冊的命名規(guī)則需要和自己的編碼規(guī)范統(tǒng)一否則反射掃描出來的名字會混亂。我們團(tuán)隊(duì)的規(guī)定是驅(qū)動(dòng)類命名必須是[廠商協(xié)議]Driver這種格式比如SiemensS7Driver、ModbusRtuDriver這樣掃描代碼才可以通過類名提取標(biāo)識符。// Platform.Host public static class KernelConfigurator { public static IKernel CreateKernel() { var kernel new StandardKernel(); var assemblies new[] { typeof(DeviceDriverModule).Assembly, typeof(Platform.Services.ServiceModule).Assembly, }; // 約定式綁定自動(dòng)掃描程序集中所有 IDeviceDriver 的實(shí)現(xiàn)類 kernel.Bind(scan scan .From(assemblies) .SelectAllClasses() .InheritedFromIDeviceDriver() .BindDefaultInterface() .Configure(binding binding.InSingletonScope())); // 手動(dòng)加載復(fù)雜綁定模塊 kernel.Load(new[] { new DeviceDriverModule() }); return kernel; } }注意這段代碼里的一個(gè)細(xì)節(jié)我同時(shí)用了約定式綁定和手動(dòng)模塊。約定式綁定解決“數(shù)量多”的問題手動(dòng)模塊解決“綁定邏輯復(fù)雜”的問題兩者互補(bǔ)。比如IDeviceDriverFactory的綁定就必須手動(dòng)寫因?yàn)樗皇悄硞€(gè)驅(qū)動(dòng)類的默認(rèn)接口約定式掃描掃不到它。4.3 配置驅(qū)動(dòng)的實(shí)例化與工廠模式有了容器和綁定真正要解決的核心問題就是“配置如何轉(zhuǎn)化為對象實(shí)例”。工業(yè)軟件的配置文件我推薦用 JSON 格式因?yàn)樗目勺x性強(qiáng)、嵌套結(jié)構(gòu)清晰而且 .NET 生態(tài)對 JSON 的支持非常成熟。我設(shè)計(jì)了一個(gè)DeviceConfig類包含設(shè)備編號、設(shè)備名稱、設(shè)備類型、通信參數(shù)等字段整個(gè)配置文件就是一個(gè)DeviceConfig的集合。{ Devices: [ { DeviceId: PLC_01, DeviceName: 主站PLC, DeviceType: Siemens, ConnectionParams: { IpAddress: 192.168.0.10, Port: 102, Rack: 0, Slot: 1 } }, { DeviceId: ROBOT_01, DeviceName: 焊接機(jī)器人, DeviceType: Modbus, ConnectionParams: { IpAddress: 192.168.0.50, Port: 502, UnitId: 1 } } ] }在程序啟動(dòng)時(shí)DeviceDriverFactory會加載這個(gè)配置遍歷設(shè)備列表逐個(gè)解析。這里的核心技巧是 Ninject 的TryGetT(string name)方法它允許你傳入綁定的名字這里是設(shè)備類型來獲取對應(yīng)實(shí)例。如果名字不存在容器會返回 null 而不是拋異常這樣可以給配置錯(cuò)誤提供友好的提示。public interface IDeviceDriverFactory { IDeviceDriver CreateDevice(DeviceConfig config); } public class DeviceDriverFactory : IDeviceDriverFactory { private readonly IKernel _kernel; public DeviceDriverFactory(IKernel kernel) { _kernel kernel; } public IDeviceDriver CreateDevice(DeviceConfig config) { // 根據(jù)配置中的設(shè)備類型字符串獲取對應(yīng)命名綁定 var driver _kernel.TryGetIDeviceDriver(config.DeviceType); if (driver null) { throw new NotSupportedException( $不支持的設(shè)備類型: {config.DeviceType}請檢查配置文件或驅(qū)動(dòng)模塊綁定。); } driver.Initialize(config); return driver; } }這里要特別說一個(gè)容易踩的坑命名綁定和工廠注入不能用同一個(gè) Kernel 實(shí)例直接注入。我在第一版代碼里試著在DeviceDriverFactory的構(gòu)造函數(shù)里注入IDeviceDriver結(jié)果發(fā)現(xiàn)根本沒法用——因?yàn)槿萜鞑恢涝摻o你注入哪個(gè)命名綁定的實(shí)例有“Siemens”“Modbus”“Mitsubishi”好幾個(gè)。正確做法是讓工廠持有IKernel本身或者更好一點(diǎn)封裝一層IDiResolver接口避免直接依賴容器在運(yùn)行時(shí)動(dòng)態(tài)解析。這在設(shè)計(jì)上是一種“服務(wù)定位器”模式雖然和純 DI 理念有點(diǎn)沖突但在這類動(dòng)態(tài)多實(shí)例場景下是最實(shí)用的折中方案。如果你不想讓業(yè)務(wù)代碼直接依賴 Ninject 的IKernel類型可以像我一樣自己封裝一個(gè)極簡的解析器接口public interface IDiResolver { TService GetTService(); TService GetTService(string name); }然后在模塊里注冊一個(gè)基于 Ninject 的實(shí)現(xiàn)NinjectDiResolver。這樣即使以后要換成 Autofac 或者 DryIoc只需要寫一個(gè)新的IDiResolver實(shí)現(xiàn)業(yè)務(wù)代碼完全不受影響。這種做法也方便單元測試時(shí)注入 mock 對象。5. 工廠模式進(jìn)階多實(shí)例設(shè)備的高效管理策略上一節(jié)里我用TryGetIDeviceDriver(config.DeviceType)解決了“怎么創(chuàng)建”的問題但實(shí)際項(xiàng)目里還有一個(gè)隱藏問題在同一臺電腦上同一個(gè)設(shè)備類型的多個(gè)實(shí)例會不會互相干擾比如產(chǎn)線上有 5 臺型號完全相同的 PLC它們用同一個(gè)驅(qū)動(dòng)類SiemensS7Driver但每臺的 IP 地址不同。如果這個(gè)驅(qū)動(dòng)類是一個(gè)簡單的無狀態(tài)通信封裝那多實(shí)例沒有問題但如果驅(qū)動(dòng)內(nèi)部緩存了連接狀態(tài)、訂閱了消息隊(duì)列那么多個(gè)實(shí)例必須保證各自的狀態(tài)不串線。更好的方案是用命名作用域或者每次創(chuàng)建新實(shí)例。Ninject 里控制對象生命周期的方法很直觀InTransientScope()表示每次解析都創(chuàng)建新對象InSingletonScope()表示全局單例InNamedScope(xxx)表示在某個(gè)命名作用域內(nèi)是單例。對于設(shè)備驅(qū)動(dòng)我最后的策略是讓驅(qū)動(dòng)類默認(rèn)是瞬態(tài)的每次工廠創(chuàng)建都是新實(shí)例但把內(nèi)部的連接池對象設(shè)置為單例。這個(gè)設(shè)計(jì)需要驅(qū)動(dòng)實(shí)現(xiàn)類配合——驅(qū)動(dòng)類本身要避免使用可靜態(tài)訪問的可變字段連接狀態(tài)全部放在實(shí)例字段里。// 設(shè)備實(shí)例需要保持獨(dú)立狀態(tài)所以用瞬態(tài)生命周期 kernel.BindIDeviceDriver() .ToSiemensS7Driver() .Named(Siemens) .InTransientScope(); // 但通信層底層的連接池是無狀態(tài)的可以安全共享 kernel.BindITransportConnectionPool() .ToTcpConnectionPool() .InSingletonScope();這里有個(gè)關(guān)鍵問題如果你用命名綁定且每個(gè)綁定都是瞬態(tài)的那么同一個(gè)名字被解析兩次會得到兩個(gè)完全不同的實(shí)例。這在我們團(tuán)隊(duì)經(jīng)歷過的場景里是個(gè)大坑——項(xiàng)目初期我們本來想緩存驅(qū)動(dòng)實(shí)例結(jié)果發(fā)現(xiàn)配置了同一個(gè)設(shè)備兩次程序里產(chǎn)生了兩份獨(dú)立連接設(shè)備端直接報(bào)“連接數(shù)超限”。后來我們專門在配置加載邏輯里做了“按 DeviceId 去重”的校驗(yàn)并且明確生命周期規(guī)則驅(qū)動(dòng)實(shí)例必須是瞬態(tài)的每個(gè)設(shè)備只允許創(chuàng)建一個(gè)實(shí)例由工廠負(fù)責(zé)緩存和銷毀。緩存機(jī)制很簡單我沒有引入復(fù)雜的管理框架直接在工廠內(nèi)部維護(hù)了一個(gè)Dictionarystring, IDeviceDriver字典的 key 是設(shè)備編號。當(dāng)CreateDevice被調(diào)用時(shí)先查字典如果存在就直接返回緩存實(shí)例不存在再創(chuàng)建并加入字典。這樣既保證了實(shí)例的唯一性又給了我們一個(gè)集中的“設(shè)備管理入口”后面做設(shè)備啟停、異常重連都很方便。另外為了避免內(nèi)存泄漏比如設(shè)備被移除后字典里的舊實(shí)例還占著連接工廠里還需要提供RemoveDevice(string deviceId)方法調(diào)用驅(qū)動(dòng)的Disconnect()并釋放資源。再補(bǔ)充一個(gè)實(shí)際項(xiàng)目里很有用的技巧不要把所有設(shè)備的創(chuàng)建過程全部放在啟動(dòng)流程里。工業(yè)現(xiàn)場經(jīng)常會遇到某個(gè)設(shè)備暫時(shí)離線的情況如果啟動(dòng)時(shí)強(qiáng)行連接所有設(shè)備一個(gè)設(shè)備連接超時(shí)會阻塞整個(gè)系統(tǒng)啟動(dòng)。我的做法是工廠提供兩個(gè)方法——CreateDevice()只負(fù)責(zé)根據(jù)配置實(shí)例化驅(qū)動(dòng)對象ConnectAll()方法則逐個(gè)嘗試連接并把失敗記錄到日志中。這樣配置好一個(gè)設(shè)備即使它沒上電系統(tǒng)也能正常啟動(dòng)只是這個(gè)設(shè)備的狀態(tài)顯示為“離線”。這個(gè)細(xì)節(jié)處理得好現(xiàn)場實(shí)施的時(shí)候能省下大量調(diào)試時(shí)間。6. WPF Prism 場景下的依賴注入擴(kuò)展實(shí)踐工業(yè)自動(dòng)化軟件的上位機(jī)界面絕大多數(shù)是 WPF 應(yīng)用。而 WPF 開發(fā)中Prism 框架是繞不開的一個(gè)話題。Prism 本身就是一套基于依賴注入的 MVVM 框架只是它的默認(rèn)容器選項(xiàng)里并沒有直接列出 Ninject而是更多推薦 Unity 或者 DryIoc。但這并不影響我們把 Ninject 整合進(jìn)來—— Prism 允許你通過自定義IContainerExtension來替換底層容器。為什么我要在 Prism 里堅(jiān)持用 Ninject 而不是直接切到 Prism 默認(rèn)推薦的容器因?yàn)槿绻紫到y(tǒng)已經(jīng)用 Ninject 寫了設(shè)備驅(qū)動(dòng)層、業(yè)務(wù)服務(wù)層的綁定我不想在一個(gè)項(xiàng)目里同時(shí)維護(hù)兩套 IoC 容器——那會帶來不必要的復(fù)雜性也讓團(tuán)隊(duì)里其他同事學(xué)習(xí)成本倍增。Prism 的Prism.Ninject包社區(qū)維護(hù)提供了現(xiàn)成的擴(kuò)展用起來很簡單但我在項(xiàng)目里發(fā)現(xiàn)它的版本迭代較慢所以在最新項(xiàng)目中我選擇自己實(shí)現(xiàn)一個(gè)極簡的IContainerExtension適配器。在 Prism 里注冊核心服務(wù)的方式通常是在App.xaml.cs中重寫CreateContainerExtension()方法然后通過RegisterTypes把 ViewModel、服務(wù)、設(shè)備模塊全部注冊進(jìn)容器。以下是我在 WPF 項(xiàng)目里的集成方式public partial class App : PrismApplication { protected override IContainerExtension CreateContainerExtension() { var kernel KernelConfigurator.CreateKernel(); return new NinjetContainerExtension(kernel); } protected override void RegisterTypes(IContainerRegistry containerRegistry) { // 注冊窗口和 ViewModel containerRegistry.RegisterForNavigationMainWindow, MainWindowViewModel(); containerRegistry.RegisterForNavigationDeviceConfigView, DeviceConfigViewModel(); containerRegistry.RegisterForNavigationProductionView, ProductionViewModel(); // 將設(shè)備工廠注冊為單例供 ViewModel 使用 containerRegistry.RegisterSingletonIDeviceDriverFactory, DeviceDriverFactory(); containerRegistry.RegisterSingletonIProductionService, ProductionService(); } }上面這段代碼里的NinjetContainerExtension是我自己寫的適配器核心就是實(shí)現(xiàn) Prism 的IContainerExtension接口把 Prism 的注冊和解析請求轉(zhuǎn)發(fā)給 Ninject 的IKernel。接口里主要要注意Resolve(Type type)和Register(Type from, Type to)這兩個(gè)方法的實(shí)現(xiàn)。這里有個(gè)坑是 Prism 會調(diào)用容器的FinalizeExtension()方法你需要在 Ninject kernel 的實(shí)例上調(diào)用kernel.Dispose()來釋放資源。在 ViewModel 層面我的實(shí)踐是讓 ViewModel 構(gòu)造函數(shù)顯式聲明依賴而不是通過ServiceLocator到處取服務(wù)。比如DeviceControlViewModel需要設(shè)備工廠、生產(chǎn)服務(wù)、日志服務(wù)構(gòu)造函數(shù)就寫成下面這樣public class DeviceControlViewModel : BindableBase { private readonly IDeviceDriverFactory _deviceFactory; private readonly IProductionService _productionService; private readonly ILogService _logService; public DeviceControlViewModel( IDeviceDriverFactory deviceFactory, IProductionService productionService, ILogService logService) { _deviceFactory deviceFactory; _productionService productionService; _logService logService; } }Prism 在解析 ViewModel 時(shí)會自動(dòng)調(diào)用容器來填充構(gòu)造函數(shù)的參數(shù)所以這些依賴都會自動(dòng)注入。這就是依賴注入在 MVVM 中最直觀的好處——ViewModel 不需要知道對象從哪來只需要聲明自己需要什么耦合度一下子就降下來了。不過這里我要提醒一句在工業(yè)軟件里不要過度追求構(gòu)造函數(shù)注入。我們有一個(gè)頁面需要彈出幾十個(gè)設(shè)備配置窗口每個(gè)窗口對應(yīng)一個(gè)設(shè)備實(shí)例如果都靠構(gòu)造函數(shù)注入會導(dǎo)致構(gòu)造函數(shù)參數(shù)爆炸。這種場景我就會選擇用屬性注入或者直接通過工廠手動(dòng)解析具體用哪種方式標(biāo)準(zhǔn)是“這個(gè)依賴是否是本對象的穩(wěn)定協(xié)作對象”。穩(wěn)定的核心服務(wù)用構(gòu)造函數(shù)注入變化的動(dòng)態(tài)實(shí)例用工廠手動(dòng)解析兩者結(jié)合才是工控軟件的最佳實(shí)踐。7. 常見問題與實(shí)戰(zhàn)排查經(jīng)驗(yàn)速查這套框架從設(shè)計(jì)到落地我在真實(shí)的工業(yè)項(xiàng)目里跑了快兩年期間遇到過不少奇奇怪怪的問題。這些問題不實(shí)際踩一遍很難從文檔里找到答案我整理成一張速查表分享給大家。癥狀可能原因排查方法解決方案啟動(dòng)時(shí)拋出ActivationException: Error activating IDeviceDriver綁定名稱拼寫錯(cuò)誤或者沒有注冊對應(yīng)的命名綁定檢查配置文件的DeviceType字段是否和模塊注冊的名字完全一致在DeviceDriverFactory的TryGet后添加空值檢查拋出帶配置信息的友好錯(cuò)誤多個(gè)設(shè)備實(shí)例互相串?dāng)?shù)據(jù)驅(qū)動(dòng)類被綁定成了單例檢查綁定代碼里是否誤用了InSingletonScope()設(shè)備驅(qū)動(dòng)改成InTransientScope()連接池等無狀態(tài)組件保持單例程序退出時(shí)卡死或拋出ObjectDisposedException沒有統(tǒng)一釋放容器和驅(qū)動(dòng)實(shí)例檢查OnExit事件是否正確調(diào)用了kernel.Dispose()在應(yīng)用退出時(shí)先調(diào)用所有設(shè)備的Disconnect()再釋放容器ViewModel 無法構(gòu)造提示缺少無參構(gòu)造函數(shù)Prism 沒有正確綁定 ViewModel 到容器檢查RegisterForNavigation是否注冊了對應(yīng)的 View/ViewModel 映射確保 ViewModel 的所有依賴都能從容器解析或者私有無參構(gòu)造函數(shù)不必存在日志里出現(xiàn)大量“綁定沖突”警告同一個(gè)接口被多個(gè)模塊重復(fù)綁定檢查是否有模塊重復(fù)將同一類型注冊到了容器約定式綁定和手動(dòng)模塊容易重復(fù)掃描時(shí)排除已手動(dòng)注冊的類型工廠創(chuàng)建的驅(qū)動(dòng)實(shí)例永遠(yuǎn)只有一個(gè)意外用了緩存機(jī)制但沒清空檢查工廠的Dictionary是否在設(shè)備移除時(shí)正確刪除補(bǔ)充RemoveDevice方法并在配置變更時(shí)重建緩存另外有幾個(gè)我在項(xiàng)目里總結(jié)的獨(dú)家經(jīng)驗(yàn)分享出來。第一個(gè)是關(guān)于IKernel注入別人的問題。Ninject 本身支持直接注入IKernel但我不建議在整個(gè)系統(tǒng)里濫用這一點(diǎn)——它會讓代碼變得很難測試。更好的做法是用我自己封裝的那個(gè)IDiResolver接口在單元測試時(shí)可以輕松 mock 掉而在正式環(huán)境里再由 Ninject 實(shí)現(xiàn)。這些細(xì)節(jié)在剛開始寫框架時(shí)可能覺得麻煩但到了項(xiàng)目中期當(dāng)你需要為每個(gè)驅(qū)動(dòng)寫單元測試時(shí)就會感謝當(dāng)初留下的這個(gè)“依賴反轉(zhuǎn)”口子。第二個(gè)是關(guān)于日志記錄在容器裝配過程中的重要性。容器啟動(dòng)時(shí)如果某個(gè)綁定寫錯(cuò)了異常信息往往含糊不清尤其在約定式掃描時(shí)你都看不出是哪個(gè)程序集的哪個(gè)類型出了問題。我的做法是在CreateKernel()方法里加上詳細(xì)的日志輸出每加載一個(gè)模塊、每完成一個(gè)約定掃描都記錄一條日志。這樣一旦啟動(dòng)失敗翻日志就能直接定位到是哪個(gè)模塊、哪個(gè)類型出了問題。第三個(gè)是關(guān)于調(diào)試時(shí)查看綁定情況。Ninject 本身提供了一個(gè)調(diào)試輔助類KernelExtensions可以輸出當(dāng)前所有綁定的快照。我寫了一個(gè)小工具方法在系統(tǒng)啟動(dòng)后把所有綁定信息序列化成字符串輸出到日志文件這樣如果你不確定某個(gè)接口到底綁定到了哪個(gè)實(shí)現(xiàn)直接看日志一下就清楚了public static string DumpBindings(IKernel kernel) { var sb new StringBuilder(); foreach (var binding in kernel.GetBindings()) { sb.AppendLine(${binding.Service.FullName} - {binding.TargetType?.FullName ?? binding.Target?.GetType().FullName}); } return sb.ToString(); }這個(gè)方法在你的系統(tǒng)里有幾十個(gè)綁定的時(shí)候真的能救人一命。8. 可配置式依賴注入框架的性能優(yōu)化與多場景適配很多做工業(yè)軟件的人一聽到“依賴注入”就會擔(dān)心性能開銷。其實(shí)我前面也說了桌面應(yīng)用場景下依賴注入的性能損耗微乎其微。但在某些特殊的工業(yè)場景下性能仍然需要認(rèn)真對待比如數(shù)據(jù)采集頻率非常高毫秒級輪詢的驅(qū)動(dòng)調(diào)用鏈路每秒鐘可能觸發(fā)幾百次服務(wù)解析。這時(shí)候如果每次都在調(diào)用鏈里走一遍容器解析確實(shí)會有明顯的開銷。我的優(yōu)化策略有三個(gè)層面。第一層面是高頻調(diào)用對象不要走容器。比如數(shù)據(jù)采集服務(wù)在啟動(dòng)時(shí)從容器里解析一次并緩存到字段里后面的輪詢循環(huán)直接用緩存引用不再走容器。這是最簡單的優(yōu)化效果也最立竿見影。說白了依賴注入解決的是“組裝問題”不是“調(diào)用問題”組裝好之后對象引用就該老老實(shí)實(shí)待著別每次都去容器里翻新。第二層面是盡量使用單例或作用域單例。對于無狀態(tài)的服務(wù)比如日志服務(wù)、配置服務(wù)直接注冊成InSingletonScope()。這樣整個(gè)程序生命周期內(nèi)只創(chuàng)建一次實(shí)例解析速度會非?？?。有狀態(tài)的組件要特別小心比如用戶會話、設(shè)備臨時(shí)狀態(tài)這些絕對不能共用單例要堅(jiān)持用瞬態(tài)或獨(dú)立實(shí)例。判斷生命周期的方式很簡單對象里如果只有配置數(shù)據(jù)和方法邏輯可以單例如果字段里保存了可變狀態(tài)就必須瞬態(tài)或獨(dú)立作用域。第三層面是在容器層面減少動(dòng)態(tài)解析。Ninject 在解析時(shí)需要通過反射查找構(gòu)造函數(shù)和綁定信息這個(gè)開銷雖然不大但高頻解析仍然會積累。我一般在設(shè)備驅(qū)動(dòng)的讀取鏈路上完全避免容器調(diào)用——驅(qū)動(dòng)對象在工廠里創(chuàng)建時(shí)是走容器的但創(chuàng)建完成后的數(shù)據(jù)讀寫循環(huán)則直接調(diào)用驅(qū)動(dòng)實(shí)例的方法不經(jīng)過任何容器。有人可能會問既然性能敏感場景下還要繞開容器那依賴注入的意義在哪里我的理解是依賴注入的價(jià)值不在調(diào)用鏈上而在系統(tǒng)組裝和擴(kuò)展的靈活性上。它讓系統(tǒng)的“靜態(tài)結(jié)構(gòu)”變得可配置、可插拔而運(yùn)行時(shí)的高頻路徑依然保持直接調(diào)用。這兩者并不矛盾關(guān)鍵是找到合適的邊界。在多場景適配方面這套基于 Ninject 的框架在我不同的項(xiàng)目里都發(fā)揮了作用。除了最典型的多設(shè)備驅(qū)動(dòng)場景在以下三類場景中它也表現(xiàn)得很好。一是仿真與實(shí)機(jī)切換。工業(yè)項(xiàng)目經(jīng)常需要先做仿真調(diào)試再在實(shí)際設(shè)備上跑。我可以在開發(fā)模式下把設(shè)備驅(qū)動(dòng)綁定到一個(gè)SimulatedDriver仿真驅(qū)動(dòng)它返回預(yù)置的模擬數(shù)據(jù)到了現(xiàn)場再把配置切換成真實(shí)驅(qū)動(dòng)。因?yàn)榻壎嗤?、接口相同業(yè)務(wù)層代碼完全不需要區(qū)分“現(xiàn)在連的是真設(shè)備還是仿真設(shè)備”。二是多語言/多協(xié)議適配。同一套上位機(jī)軟件要賣給不同客戶有的客戶用西門子有的用羅克韋爾有的用國產(chǎn)PLC。通過配置文件的設(shè)備類型字段切換綁定一套代碼搞定所有客戶。這在商務(wù)上的價(jià)值很大——定制開發(fā)變成了可選配置。三是測試與 Mock 注入。單元測試時(shí)我們可以輕松地把設(shè)備驅(qū)動(dòng)替換成 mock 實(shí)現(xiàn)或者把數(shù)據(jù)庫服務(wù)替換成內(nèi)存版本。因?yàn)橐蕾囮P(guān)系全部通過構(gòu)造函數(shù)注入測試代碼里只需要構(gòu)建一個(gè)測試用容器注冊上需要的 mock 類型就能把被測模塊隔離出來。這在傳統(tǒng)“到處 new”的代碼結(jié)構(gòu)里幾乎不可能做到。9. 最后再說幾句實(shí)在話整個(gè)框架設(shè)計(jì)下來我覺得最難的部分不是代碼怎么寫而是團(tuán)隊(duì)是否真的理解了為什么需要這樣設(shè)計(jì)。依賴注入不是一個(gè)“導(dǎo)入一個(gè) NuGet 包、加幾行代碼”就完事的操作它本質(zhì)上是一種系統(tǒng)架構(gòu)層面的思維轉(zhuǎn)變。剛開始團(tuán)隊(duì)里有人不適應(yīng)覺得“我明明直接 new 一個(gè)對象就能用干嘛非要在配置文件里繞一圈”。直到遇到客戶臨時(shí)改設(shè)備、現(xiàn)場協(xié)議不統(tǒng)一、需求頻繁迭代這些真實(shí)痛點(diǎn)之后大家才真正理解了這套設(shè)計(jì)的價(jià)值。我個(gè)人在實(shí)際操作中的體會是不要等到架構(gòu)腐化了再重構(gòu)。如果你正在做一個(gè)工業(yè)自動(dòng)化項(xiàng)目而且開始感覺到“改一個(gè)功能要?jiǎng)雍芏辔募薄靶略鲈O(shè)備類型很痛苦”“測試很難寫”那就是該引入依賴注入框架的信號。不用追求一步到位可以從設(shè)備驅(qū)動(dòng)這一層開始試點(diǎn)先把設(shè)備抽象出來再用容器管理設(shè)備實(shí)例嘗到甜頭之后再逐步推廣到服務(wù)層、界面層。最后再分享一個(gè)小技巧配置文件不要做成靜態(tài) JSON 文件就完事了。我們最終在項(xiàng)目里做了一套“配置熱更新”機(jī)制——當(dāng)設(shè)備配置文件被修改后觸發(fā)一個(gè)配置變更事件工廠會自動(dòng)對比新舊配置對新增設(shè)備調(diào)用CreateDevice對刪除設(shè)備調(diào)用RemoveDevice對參數(shù)變更的設(shè)備做重連。這樣現(xiàn)場工程師調(diào)整設(shè)備參數(shù)時(shí)完全不需要重啟軟件。當(dāng)然這個(gè)機(jī)制要做好異常處理和沖突校驗(yàn)否則配置改錯(cuò)了會導(dǎo)致設(shè)備連接出問題。這套機(jī)制的具體實(shí)現(xiàn)代碼文本里不太好完整展開但核心思路就是在設(shè)備工廠里維護(hù)配置的“版本號”監(jiān)聽文件變化變化后走一次“增量應(yīng)用”流程。如果你正在構(gòu)建自己的工業(yè)自動(dòng)化軟件或者正在為“設(shè)備驅(qū)動(dòng)一換就要改代碼”頭疼我希望這篇文章能給你足夠的參考和信心。依賴注入不是互聯(lián)網(wǎng)大廠專屬的玩具在工控軟件里它同樣值得作為核心架構(gòu)的一部分來認(rèn)真設(shè)計(jì)和實(shí)踐。 基于Ninject的可配置式依賴注入框架：工業(yè)自動(dòng)化軟件解耦實(shí)踐
1. 項(xiàng)目概述為什么工業(yè)自動(dòng)化軟件需要一套自己的依賴注入方案這幾年一直在做工業(yè)自動(dòng)化上位機(jī)軟件從早期的簡單工控界面到后來的整線調(diào)度系統(tǒng)項(xiàng)目越做越大代碼結(jié)構(gòu)也從一開始的“能跑就行”變成了后來的“改一個(gè)地方崩三個(gè)地方”。真正讓我下定決心重構(gòu)依賴關(guān)系的是一次設(shè)備層驅(qū)動(dòng)的替換——因?yàn)楣?yīng)商換了通信協(xié)議我需要把底層串口通信類換成TCP版本結(jié)果牽扯到界面層、業(yè)務(wù)層、數(shù)據(jù)處理層十幾個(gè)文件都要跟著改光是排查引用關(guān)系就花了整整兩天。那時(shí)候我意識到工業(yè)自動(dòng)化軟件雖然不像互聯(lián)網(wǎng)系統(tǒng)那樣追求極致的并發(fā)和彈性但它的設(shè)備類型多、通信協(xié)議雜、現(xiàn)場需求變化快如果沒有一套合理的解耦機(jī)制維護(hù)成本會隨著項(xiàng)目迭代指數(shù)級上升。簡單來說依賴注入Dependency Injection簡稱DI和IoC容器Inversion of Control控制反轉(zhuǎn)容器解決的核心問題就是對象不應(yīng)該自己 new 自己依賴的東西而應(yīng)該由外部統(tǒng)一創(chuàng)建并“注入”進(jìn)來。這個(gè)思想在很多互聯(lián)網(wǎng)項(xiàng)目中已經(jīng)是非常基礎(chǔ)的實(shí)踐了但在工業(yè)自動(dòng)化領(lǐng)域尤其是很多老牌工控軟件團(tuán)隊(duì)里還停留在“工具類全部static、設(shè)備驅(qū)動(dòng)寫死在構(gòu)造函數(shù)里、換一個(gè)硬件型號就要改源碼重新編譯”的階段。我寫這套基于 Ninject 的可配置式依賴注入框架目標(biāo)很明確——讓工業(yè)自動(dòng)化軟件的模塊像樂高積木一樣可以在不修改代碼的前提下通過配置文件調(diào)整組裝方式適應(yīng)不同產(chǎn)線、不同設(shè)備、不同通信協(xié)議的需求。這套方案適合誰參考如果你正在做 .NET 平臺的工控上位機(jī)、SCADA系統(tǒng)、設(shè)備調(diào)度軟件或者任何涉及多種硬件設(shè)備接入、通信協(xié)議頻繁變更的桌面應(yīng)用這篇文章里關(guān)于依賴注入容器選型、模塊化裝配、配置驅(qū)動(dòng)實(shí)例化、作用域管理的思路都可以直接借鑒。我會把完整的設(shè)計(jì)思路、核心代碼實(shí)現(xiàn)、以及我在實(shí)際項(xiàng)目中踩過的坑都寫出來盡量做到拿來即用。2. 方案選型為什么是 Ninject 而不是其他 IoC 容器在定下使用 Ninject 之前我其實(shí)對比過 .NET 生態(tài)里幾個(gè)主流的依賴注入容器包括微軟官方推薦的 Unity、性能和功能都很全面的 Autofac以及輕量級的 DryIoc。每個(gè)容器都有自己的生態(tài)位但在工業(yè)自動(dòng)化這個(gè)特定場景下Ninject 有幾個(gè)非常突出的優(yōu)勢值得展開說一下。首先Ninject 的綁定語法在“條件式綁定”和“約定式綁定”上非常靈活。工業(yè)自動(dòng)化軟件里最典型的場景就是“同一接口有多個(gè)實(shí)現(xiàn)”比如我定義一個(gè)IDeviceDriver接口可能有西門子PLC驅(qū)動(dòng)、Modbus驅(qū)動(dòng)、三菱驅(qū)動(dòng)等多個(gè)實(shí)現(xiàn)類。在運(yùn)行時(shí)到底該注入哪個(gè)實(shí)現(xiàn)取決于現(xiàn)場的配置文件或者設(shè)備類型。Ninject 支持通過When()條件來動(dòng)態(tài)選擇綁定也支持通過約定Convention批量掃描程序集自動(dòng)注冊這兩點(diǎn)正好命中工控軟件的痛點(diǎn)。其次Ninject 的kernel 是可擴(kuò)展的。它的核心設(shè)計(jì)基于“組件”模式你可以在不修改容器源碼的情況下通過實(shí)現(xiàn)IResolveExtension或自定義IProvider來擴(kuò)展實(shí)例創(chuàng)建的策略。這一點(diǎn)對于工業(yè)現(xiàn)場那種“某些設(shè)備驅(qū)動(dòng)必須保持單例某些通信對象必須每次新建”的復(fù)雜生命周期需求來說非常友好。我選擇 Ninject 還有一個(gè)很重要的現(xiàn)實(shí)原因——它在 WPF/WinForms 這類桌面技術(shù)棧里集成非常順滑。工業(yè)自動(dòng)化軟件絕大多數(shù)是桌面應(yīng)用這跟互聯(lián)網(wǎng)項(xiàng)目完全不同而 Ninject 對INotifyPropertyChanged、Prism這類 MVVM 框架的適配做得比較成熟。后面我會專門用一節(jié)講 Ninject 和 Prism 的聯(lián)動(dòng)這是我們這類項(xiàng)目繞不開的話題。當(dāng)然Ninject 也有它的問題最明顯的是性能比 Autofac 略遜一籌。但說實(shí)話在工控上位機(jī)這種場景里對象創(chuàng)建的頻率和互聯(lián)網(wǎng)高并發(fā)根本不在一個(gè)量級。一個(gè)界面啟動(dòng)時(shí)創(chuàng)建幾十個(gè)對象就算每個(gè)多花零點(diǎn)幾毫秒用戶也完全感知不到。我判斷一個(gè)技術(shù)選型是否合適核心標(biāo)準(zhǔn)是“在滿足需求的前提下最小化團(tuán)隊(duì)理解和維護(hù)成本”Ninject 恰好就是這個(gè)平衡點(diǎn)。3. 框架總體結(jié)構(gòu)從設(shè)備驅(qū)動(dòng)到界面層的完整解耦設(shè)計(jì)這一節(jié)是整個(gè)方案的主干。我要設(shè)計(jì)的不僅僅是用 Ninject 做幾個(gè)類的注入而是一套完整的、可配置的架構(gòu)讓工業(yè)自動(dòng)化軟件的各個(gè)層次都建立起清晰的依賴邊界。在設(shè)計(jì)這套框架之前我梳理了工業(yè)自動(dòng)化軟件的幾個(gè)典型層次界面層人機(jī)交互、業(yè)務(wù)流程層工藝邏輯、生產(chǎn)流程、設(shè)備抽象層PLC、傳感器、機(jī)器人、視覺系統(tǒng)等硬件封裝、通信層串口、TCP/IP、Profinet、EtherCAT等、數(shù)據(jù)處理層數(shù)據(jù)采集、存儲、報(bào)表。傳統(tǒng)寫法里這些層次之間經(jīng)常是直接引用、直接 new 的關(guān)系比如界面層里就寫著var driver new SiemensPLCDriver(192.168.0.1)。這樣的代碼在單一設(shè)備、單一協(xié)議的小項(xiàng)目里沒有大問題但一旦項(xiàng)目變成“支持5種PLC、3種機(jī)器人、2種視覺系統(tǒng)”的整線方案這種強(qiáng)耦合關(guān)系就會變成災(zāi)難。我的設(shè)計(jì)思路是定義清晰的接口契約所有依賴都面向接口編程對象之間的組裝關(guān)系全部交給 Ioc 容器管理。第一版框架我規(guī)劃了三個(gè)核心程序集Platform.Abstractions抽象層定義接口和基礎(chǔ)實(shí)體、Platform.DeviceDrivers設(shè)備驅(qū)動(dòng)實(shí)現(xiàn)、Platform.Host宿主程序負(fù)責(zé)裝配容器、加載配置、啟動(dòng)流程。拿設(shè)備驅(qū)動(dòng)來舉例這是工業(yè)軟件里最容易變也最關(guān)鍵的部分。我定義了一個(gè)IDeviceDriver接口它包含Connect()、Disconnect()、ReadData(string tag)、WriteData(string tag, object value)等基礎(chǔ)方法以及DeviceStatus狀態(tài)屬性。不同廠商的 PLC 通信協(xié)議完全不一樣但只要它們都實(shí)現(xiàn)了這個(gè)接口上層業(yè)務(wù)代碼就完全不需要關(guān)心底層協(xié)議細(xì)節(jié)。業(yè)務(wù)層只要寫“從運(yùn)維水站讀取溫度值”而不需要知道這個(gè)溫度值是通過 S7 協(xié)議還是 Modbus TCP 讀上來的。在設(shè)計(jì)這套框架時(shí)我還額外抽象了一層“設(shè)備工廠”的概念。為什么需要設(shè)備工廠因?yàn)楣た噩F(xiàn)場存在大量“動(dòng)態(tài)創(chuàng)建設(shè)備實(shí)例”的場景。比如一個(gè)配置系統(tǒng)里用戶根據(jù)產(chǎn)線實(shí)際布局在配置界面添加了5臺PLC和3臺機(jī)器人程序啟動(dòng)時(shí)需要根據(jù)配置信息實(shí)例化8個(gè)驅(qū)動(dòng)對象而且每臺設(shè)備的參數(shù)IP地址、端口、站號各不相同。這時(shí)候如果還是用構(gòu)造函數(shù)直接注入你會發(fā)現(xiàn)沒法注入——因?yàn)槟愀静恢绬?dòng)時(shí)需要多少個(gè)實(shí)例。我的方案是定義一個(gè)IDeviceDriverFactory它接收配置項(xiàng)DeviceConfig作為參數(shù)根據(jù)配置里的DeviceType字段用 Ninject 的 Kernel 動(dòng)態(tài)獲取對應(yīng)類型的實(shí)例然后初始化參數(shù)后返回。這樣一來設(shè)備數(shù)量、類型、參數(shù)全部配置化代碼里只維護(hù)“如何創(chuàng)建”的規(guī)則而不關(guān)心“創(chuàng)建誰”和“創(chuàng)建幾個(gè)”。這套結(jié)構(gòu)的好處在實(shí)際項(xiàng)目中體現(xiàn)得非常直接。我們曾經(jīng)有一個(gè)項(xiàng)目前期調(diào)研時(shí)客戶說用的是西門子 S7-1200 PLC代碼寫好后到現(xiàn)場實(shí)施時(shí)客戶突然說有一臺設(shè)備換成了三菱FX5U。放在以前這意味著一大波代碼修改和重新編譯部署。但在新框架下我只需要在配置文件的設(shè)備列表里加一條新記錄指定設(shè)備類型為MitsubishiDriver填上 IP 和端口號重啟程序就完事了——業(yè)務(wù)層代碼一行都不用動(dòng)。這就是解耦帶來的直接收益。4. 核心實(shí)現(xiàn)詳解Ninject 模塊化配置與裝配容器設(shè)計(jì)4.1 統(tǒng)一定義 Ninject 模塊Ninject 里有“模塊Module”的概念你可以把一組相關(guān)的綁定封裝到一個(gè)模塊里然后統(tǒng)一加載。在工業(yè)自動(dòng)化框架里我按“功能域”來劃分模塊每個(gè)功能域?qū)?yīng)一個(gè) Ninject 模塊設(shè)備驅(qū)動(dòng)注冊到一個(gè)驅(qū)動(dòng)模塊通信層注冊到通信模塊業(yè)務(wù)服務(wù)注冊到服務(wù)模塊界面層需要的 ViewModel 注冊到界面模塊。每個(gè)模塊類繼承NinjectModule在Load()方法里定義綁定關(guān)系。下面是我在項(xiàng)目中實(shí)際使用的模塊定義代碼。這里我定義一個(gè)統(tǒng)一的接口IDependencyModule方便后續(xù)用反射統(tǒng)一掃描和加載模塊。// Platform.Abstractions public interface IDependencyModule { void LoadBindings(IKernel kernel); } // Platform.DeviceDrivers public class DeviceDriverModule : IDependencyModule { public void LoadBindings(IKernel kernel) { // 默認(rèn)綁定沒有指定具體類型時(shí)使用通用驅(qū)動(dòng) kernel.BindIDeviceDriver().ToGenericDriver(); // 命名綁定按設(shè)備類型區(qū)分不同廠商的驅(qū)動(dòng)實(shí)現(xiàn) kernel.BindIDeviceDriver().ToSiemensS7Driver().Named(Siemens); kernel.BindIDeviceDriver().ToModbusTcpDriver().Named(Modbus); kernel.BindIDeviceDriver().ToMitsubishiDriver().Named(Mitsubishi); // 設(shè)備工廠單例工廠本身無狀態(tài)整個(gè)系統(tǒng)只需要一個(gè)實(shí)例 kernel.BindIDeviceDriverFactory().ToDeviceDriverFactory().InSingletonScope(); } }這里有個(gè)非常重要的設(shè)計(jì)——命名綁定。Ninject 允許你給同一個(gè)接口的不同實(shí)現(xiàn)綁定不同的名字然后在解析時(shí)通過名字精確獲取。在很多場景里我們可以提前知道設(shè)備的類型比如從配置文件的DeviceType字段讀取字符串值然后用這個(gè)名字去容器里找對應(yīng)的實(shí)現(xiàn)。這個(gè)方法比寫一堆if (type Siemens) return new SiemensDriver();的硬編碼優(yōu)雅得多而且新增一種設(shè)備驅(qū)動(dòng)時(shí)只需要增加一個(gè)新的綁定和一個(gè)實(shí)現(xiàn)類不需要改動(dòng)工廠方法。4.2 約定式掃描自動(dòng)注冊除了手動(dòng)綁定Ninject 還支持約定式綁定Convention Binding。你可以讓它自動(dòng)掃描某個(gè)程序集中的所有類型找到實(shí)現(xiàn)某類接口的類型自動(dòng)建立綁定關(guān)系。這在工業(yè)軟件里的價(jià)值非常大——因?yàn)轵?qū)動(dòng)數(shù)量會持續(xù)增長每增加一個(gè)新設(shè)備的驅(qū)動(dòng)如果都要手動(dòng)寫一行Bind代碼雖然不累但容易漏。我用Ninject.Extensions.Conventions擴(kuò)展來實(shí)現(xiàn)自動(dòng)注冊。核心邏輯是掃描所有以Driver結(jié)尾的類型找出它們實(shí)現(xiàn)的IDeviceDriver接口以類名的前綴作為綁定名自動(dòng)注冊。當(dāng)然自動(dòng)注冊的命名規(guī)則需要和自己的編碼規(guī)范統(tǒng)一否則反射掃描出來的名字會混亂。我們團(tuán)隊(duì)的規(guī)定是驅(qū)動(dòng)類命名必須是[廠商協(xié)議]Driver這種格式比如SiemensS7Driver、ModbusRtuDriver這樣掃描代碼才可以通過類名提取標(biāo)識符。// Platform.Host public static class KernelConfigurator { public static IKernel CreateKernel() { var kernel new StandardKernel(); var assemblies new[] { typeof(DeviceDriverModule).Assembly, typeof(Platform.Services.ServiceModule).Assembly, }; // 約定式綁定自動(dòng)掃描程序集中所有 IDeviceDriver 的實(shí)現(xiàn)類 kernel.Bind(scan scan .From(assemblies) .SelectAllClasses() .InheritedFromIDeviceDriver() .BindDefaultInterface() .Configure(binding binding.InSingletonScope())); // 手動(dòng)加載復(fù)雜綁定模塊 kernel.Load(new[] { new DeviceDriverModule() }); return kernel; } }注意這段代碼里的一個(gè)細(xì)節(jié)我同時(shí)用了約定式綁定和手動(dòng)模塊。約定式綁定解決“數(shù)量多”的問題手動(dòng)模塊解決“綁定邏輯復(fù)雜”的問題兩者互補(bǔ)。比如IDeviceDriverFactory的綁定就必須手動(dòng)寫因?yàn)樗皇悄硞€(gè)驅(qū)動(dòng)類的默認(rèn)接口約定式掃描掃不到它。4.3 配置驅(qū)動(dòng)的實(shí)例化與工廠模式有了容器和綁定真正要解決的核心問題就是“配置如何轉(zhuǎn)化為對象實(shí)例”。工業(yè)軟件的配置文件我推薦用 JSON 格式因?yàn)樗目勺x性強(qiáng)、嵌套結(jié)構(gòu)清晰而且 .NET 生態(tài)對 JSON 的支持非常成熟。我設(shè)計(jì)了一個(gè)DeviceConfig類包含設(shè)備編號、設(shè)備名稱、設(shè)備類型、通信參數(shù)等字段整個(gè)配置文件就是一個(gè)DeviceConfig的集合。{ Devices: [ { DeviceId: PLC_01, DeviceName: 主站PLC, DeviceType: Siemens, ConnectionParams: { IpAddress: 192.168.0.10, Port: 102, Rack: 0, Slot: 1 } }, { DeviceId: ROBOT_01, DeviceName: 焊接機(jī)器人, DeviceType: Modbus, ConnectionParams: { IpAddress: 192.168.0.50, Port: 502, UnitId: 1 } } ] }在程序啟動(dòng)時(shí)DeviceDriverFactory會加載這個(gè)配置遍歷設(shè)備列表逐個(gè)解析。這里的核心技巧是 Ninject 的TryGetT(string name)方法它允許你傳入綁定的名字這里是設(shè)備類型來獲取對應(yīng)實(shí)例。如果名字不存在容器會返回 null 而不是拋異常這樣可以給配置錯(cuò)誤提供友好的提示。public interface IDeviceDriverFactory { IDeviceDriver CreateDevice(DeviceConfig config); } public class DeviceDriverFactory : IDeviceDriverFactory { private readonly IKernel _kernel; public DeviceDriverFactory(IKernel kernel) { _kernel kernel; } public IDeviceDriver CreateDevice(DeviceConfig config) { // 根據(jù)配置中的設(shè)備類型字符串獲取對應(yīng)命名綁定 var driver _kernel.TryGetIDeviceDriver(config.DeviceType); if (driver null) { throw new NotSupportedException( $不支持的設(shè)備類型: {config.DeviceType}請檢查配置文件或驅(qū)動(dòng)模塊綁定。); } driver.Initialize(config); return driver; } }這里要特別說一個(gè)容易踩的坑命名綁定和工廠注入不能用同一個(gè) Kernel 實(shí)例直接注入。我在第一版代碼里試著在DeviceDriverFactory的構(gòu)造函數(shù)里注入IDeviceDriver結(jié)果發(fā)現(xiàn)根本沒法用——因?yàn)槿萜鞑恢涝摻o你注入哪個(gè)命名綁定的實(shí)例有“Siemens”“Modbus”“Mitsubishi”好幾個(gè)。正確做法是讓工廠持有IKernel本身或者更好一點(diǎn)封裝一層IDiResolver接口避免直接依賴容器在運(yùn)行時(shí)動(dòng)態(tài)解析。這在設(shè)計(jì)上是一種“服務(wù)定位器”模式雖然和純 DI 理念有點(diǎn)沖突但在這類動(dòng)態(tài)多實(shí)例場景下是最實(shí)用的折中方案。如果你不想讓業(yè)務(wù)代碼直接依賴 Ninject 的IKernel類型可以像我一樣自己封裝一個(gè)極簡的解析器接口public interface IDiResolver { TService GetTService(); TService GetTService(string name); }然后在模塊里注冊一個(gè)基于 Ninject 的實(shí)現(xiàn)NinjectDiResolver。這樣即使以后要換成 Autofac 或者 DryIoc只需要寫一個(gè)新的IDiResolver實(shí)現(xiàn)業(yè)務(wù)代碼完全不受影響。這種做法也方便單元測試時(shí)注入 mock 對象。5. 工廠模式進(jìn)階多實(shí)例設(shè)備的高效管理策略上一節(jié)里我用TryGetIDeviceDriver(config.DeviceType)解決了“怎么創(chuàng)建”的問題但實(shí)際項(xiàng)目里還有一個(gè)隱藏問題在同一臺電腦上同一個(gè)設(shè)備類型的多個(gè)實(shí)例會不會互相干擾比如產(chǎn)線上有 5 臺型號完全相同的 PLC它們用同一個(gè)驅(qū)動(dòng)類SiemensS7Driver但每臺的 IP 地址不同。如果這個(gè)驅(qū)動(dòng)類是一個(gè)簡單的無狀態(tài)通信封裝那多實(shí)例沒有問題但如果驅(qū)動(dòng)內(nèi)部緩存了連接狀態(tài)、訂閱了消息隊(duì)列那么多個(gè)實(shí)例必須保證各自的狀態(tài)不串線。更好的方案是用命名作用域或者每次創(chuàng)建新實(shí)例。Ninject 里控制對象生命周期的方法很直觀InTransientScope()表示每次解析都創(chuàng)建新對象InSingletonScope()表示全局單例InNamedScope(xxx)表示在某個(gè)命名作用域內(nèi)是單例。對于設(shè)備驅(qū)動(dòng)我最后的策略是讓驅(qū)動(dòng)類默認(rèn)是瞬態(tài)的每次工廠創(chuàng)建都是新實(shí)例但把內(nèi)部的連接池對象設(shè)置為單例。這個(gè)設(shè)計(jì)需要驅(qū)動(dòng)實(shí)現(xiàn)類配合——驅(qū)動(dòng)類本身要避免使用可靜態(tài)訪問的可變字段連接狀態(tài)全部放在實(shí)例字段里。// 設(shè)備實(shí)例需要保持獨(dú)立狀態(tài)所以用瞬態(tài)生命周期 kernel.BindIDeviceDriver() .ToSiemensS7Driver() .Named(Siemens) .InTransientScope(); // 但通信層底層的連接池是無狀態(tài)的可以安全共享 kernel.BindITransportConnectionPool() .ToTcpConnectionPool() .InSingletonScope();這里有個(gè)關(guān)鍵問題如果你用命名綁定且每個(gè)綁定都是瞬態(tài)的那么同一個(gè)名字被解析兩次會得到兩個(gè)完全不同的實(shí)例。這在我們團(tuán)隊(duì)經(jīng)歷過的場景里是個(gè)大坑——項(xiàng)目初期我們本來想緩存驅(qū)動(dòng)實(shí)例結(jié)果發(fā)現(xiàn)配置了同一個(gè)設(shè)備兩次程序里產(chǎn)生了兩份獨(dú)立連接設(shè)備端直接報(bào)“連接數(shù)超限”。后來我們專門在配置加載邏輯里做了“按 DeviceId 去重”的校驗(yàn)并且明確生命周期規(guī)則驅(qū)動(dòng)實(shí)例必須是瞬態(tài)的每個(gè)設(shè)備只允許創(chuàng)建一個(gè)實(shí)例由工廠負(fù)責(zé)緩存和銷毀。緩存機(jī)制很簡單我沒有引入復(fù)雜的管理框架直接在工廠內(nèi)部維護(hù)了一個(gè)Dictionarystring, IDeviceDriver字典的 key 是設(shè)備編號。當(dāng)CreateDevice被調(diào)用時(shí)先查字典如果存在就直接返回緩存實(shí)例不存在再創(chuàng)建并加入字典。這樣既保證了實(shí)例的唯一性又給了我們一個(gè)集中的“設(shè)備管理入口”后面做設(shè)備啟停、異常重連都很方便。另外為了避免內(nèi)存泄漏比如設(shè)備被移除后字典里的舊實(shí)例還占著連接工廠里還需要提供RemoveDevice(string deviceId)方法調(diào)用驅(qū)動(dòng)的Disconnect()并釋放資源。再補(bǔ)充一個(gè)實(shí)際項(xiàng)目里很有用的技巧不要把所有設(shè)備的創(chuàng)建過程全部放在啟動(dòng)流程里。工業(yè)現(xiàn)場經(jīng)常會遇到某個(gè)設(shè)備暫時(shí)離線的情況如果啟動(dòng)時(shí)強(qiáng)行連接所有設(shè)備一個(gè)設(shè)備連接超時(shí)會阻塞整個(gè)系統(tǒng)啟動(dòng)。我的做法是工廠提供兩個(gè)方法——CreateDevice()只負(fù)責(zé)根據(jù)配置實(shí)例化驅(qū)動(dòng)對象ConnectAll()方法則逐個(gè)嘗試連接并把失敗記錄到日志中。這樣配置好一個(gè)設(shè)備即使它沒上電系統(tǒng)也能正常啟動(dòng)只是這個(gè)設(shè)備的狀態(tài)顯示為“離線”。這個(gè)細(xì)節(jié)處理得好現(xiàn)場實(shí)施的時(shí)候能省下大量調(diào)試時(shí)間。6. WPF Prism 場景下的依賴注入擴(kuò)展實(shí)踐工業(yè)自動(dòng)化軟件的上位機(jī)界面絕大多數(shù)是 WPF 應(yīng)用。而 WPF 開發(fā)中Prism 框架是繞不開的一個(gè)話題。Prism 本身就是一套基于依賴注入的 MVVM 框架只是它的默認(rèn)容器選項(xiàng)里并沒有直接列出 Ninject而是更多推薦 Unity 或者 DryIoc。但這并不影響我們把 Ninject 整合進(jìn)來—— Prism 允許你通過自定義IContainerExtension來替換底層容器。為什么我要在 Prism 里堅(jiān)持用 Ninject 而不是直接切到 Prism 默認(rèn)推薦的容器因?yàn)槿绻紫到y(tǒng)已經(jīng)用 Ninject 寫了設(shè)備驅(qū)動(dòng)層、業(yè)務(wù)服務(wù)層的綁定我不想在一個(gè)項(xiàng)目里同時(shí)維護(hù)兩套 IoC 容器——那會帶來不必要的復(fù)雜性也讓團(tuán)隊(duì)里其他同事學(xué)習(xí)成本倍增。Prism 的Prism.Ninject包社區(qū)維護(hù)提供了現(xiàn)成的擴(kuò)展用起來很簡單但我在項(xiàng)目里發(fā)現(xiàn)它的版本迭代較慢所以在最新項(xiàng)目中我選擇自己實(shí)現(xiàn)一個(gè)極簡的IContainerExtension適配器。在 Prism 里注冊核心服務(wù)的方式通常是在App.xaml.cs中重寫CreateContainerExtension()方法然后通過RegisterTypes把 ViewModel、服務(wù)、設(shè)備模塊全部注冊進(jìn)容器。以下是我在 WPF 項(xiàng)目里的集成方式public partial class App : PrismApplication { protected override IContainerExtension CreateContainerExtension() { var kernel KernelConfigurator.CreateKernel(); return new NinjetContainerExtension(kernel); } protected override void RegisterTypes(IContainerRegistry containerRegistry) { // 注冊窗口和 ViewModel containerRegistry.RegisterForNavigationMainWindow, MainWindowViewModel(); containerRegistry.RegisterForNavigationDeviceConfigView, DeviceConfigViewModel(); containerRegistry.RegisterForNavigationProductionView, ProductionViewModel(); // 將設(shè)備工廠注冊為單例供 ViewModel 使用 containerRegistry.RegisterSingletonIDeviceDriverFactory, DeviceDriverFactory(); containerRegistry.RegisterSingletonIProductionService, ProductionService(); } }上面這段代碼里的NinjetContainerExtension是我自己寫的適配器核心就是實(shí)現(xiàn) Prism 的IContainerExtension接口把 Prism 的注冊和解析請求轉(zhuǎn)發(fā)給 Ninject 的IKernel。接口里主要要注意Resolve(Type type)和Register(Type from, Type to)這兩個(gè)方法的實(shí)現(xiàn)。這里有個(gè)坑是 Prism 會調(diào)用容器的FinalizeExtension()方法你需要在 Ninject kernel 的實(shí)例上調(diào)用kernel.Dispose()來釋放資源。在 ViewModel 層面我的實(shí)踐是讓 ViewModel 構(gòu)造函數(shù)顯式聲明依賴而不是通過ServiceLocator到處取服務(wù)。比如DeviceControlViewModel需要設(shè)備工廠、生產(chǎn)服務(wù)、日志服務(wù)構(gòu)造函數(shù)就寫成下面這樣public class DeviceControlViewModel : BindableBase { private readonly IDeviceDriverFactory _deviceFactory; private readonly IProductionService _productionService; private readonly ILogService _logService; public DeviceControlViewModel( IDeviceDriverFactory deviceFactory, IProductionService productionService, ILogService logService) { _deviceFactory deviceFactory; _productionService productionService; _logService logService; } }Prism 在解析 ViewModel 時(shí)會自動(dòng)調(diào)用容器來填充構(gòu)造函數(shù)的參數(shù)所以這些依賴都會自動(dòng)注入。這就是依賴注入在 MVVM 中最直觀的好處——ViewModel 不需要知道對象從哪來只需要聲明自己需要什么耦合度一下子就降下來了。不過這里我要提醒一句在工業(yè)軟件里不要過度追求構(gòu)造函數(shù)注入。我們有一個(gè)頁面需要彈出幾十個(gè)設(shè)備配置窗口每個(gè)窗口對應(yīng)一個(gè)設(shè)備實(shí)例如果都靠構(gòu)造函數(shù)注入會導(dǎo)致構(gòu)造函數(shù)參數(shù)爆炸。這種場景我就會選擇用屬性注入或者直接通過工廠手動(dòng)解析具體用哪種方式標(biāo)準(zhǔn)是“這個(gè)依賴是否是本對象的穩(wěn)定協(xié)作對象”。穩(wěn)定的核心服務(wù)用構(gòu)造函數(shù)注入變化的動(dòng)態(tài)實(shí)例用工廠手動(dòng)解析兩者結(jié)合才是工控軟件的最佳實(shí)踐。7. 常見問題與實(shí)戰(zhàn)排查經(jīng)驗(yàn)速查這套框架從設(shè)計(jì)到落地我在真實(shí)的工業(yè)項(xiàng)目里跑了快兩年期間遇到過不少奇奇怪怪的問題。這些問題不實(shí)際踩一遍很難從文檔里找到答案我整理成一張速查表分享給大家。癥狀可能原因排查方法解決方案啟動(dòng)時(shí)拋出ActivationException: Error activating IDeviceDriver綁定名稱拼寫錯(cuò)誤或者沒有注冊對應(yīng)的命名綁定檢查配置文件的DeviceType字段是否和模塊注冊的名字完全一致在DeviceDriverFactory的TryGet后添加空值檢查拋出帶配置信息的友好錯(cuò)誤多個(gè)設(shè)備實(shí)例互相串?dāng)?shù)據(jù)驅(qū)動(dòng)類被綁定成了單例檢查綁定代碼里是否誤用了InSingletonScope()設(shè)備驅(qū)動(dòng)改成InTransientScope()連接池等無狀態(tài)組件保持單例程序退出時(shí)卡死或拋出ObjectDisposedException沒有統(tǒng)一釋放容器和驅(qū)動(dòng)實(shí)例檢查OnExit事件是否正確調(diào)用了kernel.Dispose()在應(yīng)用退出時(shí)先調(diào)用所有設(shè)備的Disconnect()再釋放容器ViewModel 無法構(gòu)造提示缺少無參構(gòu)造函數(shù)Prism 沒有正確綁定 ViewModel 到容器檢查RegisterForNavigation是否注冊了對應(yīng)的 View/ViewModel 映射確保 ViewModel 的所有依賴都能從容器解析或者私有無參構(gòu)造函數(shù)不必存在日志里出現(xiàn)大量“綁定沖突”警告同一個(gè)接口被多個(gè)模塊重復(fù)綁定檢查是否有模塊重復(fù)將同一類型注冊到了容器約定式綁定和手動(dòng)模塊容易重復(fù)掃描時(shí)排除已手動(dòng)注冊的類型工廠創(chuàng)建的驅(qū)動(dòng)實(shí)例永遠(yuǎn)只有一個(gè)意外用了緩存機(jī)制但沒清空檢查工廠的Dictionary是否在設(shè)備移除時(shí)正確刪除補(bǔ)充RemoveDevice方法并在配置變更時(shí)重建緩存另外有幾個(gè)我在項(xiàng)目里總結(jié)的獨(dú)家經(jīng)驗(yàn)分享出來。第一個(gè)是關(guān)于IKernel注入別人的問題。Ninject 本身支持直接注入IKernel但我不建議在整個(gè)系統(tǒng)里濫用這一點(diǎn)——它會讓代碼變得很難測試。更好的做法是用我自己封裝的那個(gè)IDiResolver接口在單元測試時(shí)可以輕松 mock 掉而在正式環(huán)境里再由 Ninject 實(shí)現(xiàn)。這些細(xì)節(jié)在剛開始寫框架時(shí)可能覺得麻煩但到了項(xiàng)目中期當(dāng)你需要為每個(gè)驅(qū)動(dòng)寫單元測試時(shí)就會感謝當(dāng)初留下的這個(gè)“依賴反轉(zhuǎn)”口子。第二個(gè)是關(guān)于日志記錄在容器裝配過程中的重要性。容器啟動(dòng)時(shí)如果某個(gè)綁定寫錯(cuò)了異常信息往往含糊不清尤其在約定式掃描時(shí)你都看不出是哪個(gè)程序集的哪個(gè)類型出了問題。我的做法是在CreateKernel()方法里加上詳細(xì)的日志輸出每加載一個(gè)模塊、每完成一個(gè)約定掃描都記錄一條日志。這樣一旦啟動(dòng)失敗翻日志就能直接定位到是哪個(gè)模塊、哪個(gè)類型出了問題。第三個(gè)是關(guān)于調(diào)試時(shí)查看綁定情況。Ninject 本身提供了一個(gè)調(diào)試輔助類KernelExtensions可以輸出當(dāng)前所有綁定的快照。我寫了一個(gè)小工具方法在系統(tǒng)啟動(dòng)后把所有綁定信息序列化成字符串輸出到日志文件這樣如果你不確定某個(gè)接口到底綁定到了哪個(gè)實(shí)現(xiàn)直接看日志一下就清楚了public static string DumpBindings(IKernel kernel) { var sb new StringBuilder(); foreach (var binding in kernel.GetBindings()) { sb.AppendLine(${binding.Service.FullName} - {binding.TargetType?.FullName ?? binding.Target?.GetType().FullName}); } return sb.ToString(); }這個(gè)方法在你的系統(tǒng)里有幾十個(gè)綁定的時(shí)候真的能救人一命。8. 可配置式依賴注入框架的性能優(yōu)化與多場景適配很多做工業(yè)軟件的人一聽到“依賴注入”就會擔(dān)心性能開銷。其實(shí)我前面也說了桌面應(yīng)用場景下依賴注入的性能損耗微乎其微。但在某些特殊的工業(yè)場景下性能仍然需要認(rèn)真對待比如數(shù)據(jù)采集頻率非常高毫秒級輪詢的驅(qū)動(dòng)調(diào)用鏈路每秒鐘可能觸發(fā)幾百次服務(wù)解析。這時(shí)候如果每次都在調(diào)用鏈里走一遍容器解析確實(shí)會有明顯的開銷。我的優(yōu)化策略有三個(gè)層面。第一層面是高頻調(diào)用對象不要走容器。比如數(shù)據(jù)采集服務(wù)在啟動(dòng)時(shí)從容器里解析一次并緩存到字段里后面的輪詢循環(huán)直接用緩存引用不再走容器。這是最簡單的優(yōu)化效果也最立竿見影。說白了依賴注入解決的是“組裝問題”不是“調(diào)用問題”組裝好之后對象引用就該老老實(shí)實(shí)待著別每次都去容器里翻新。第二層面是盡量使用單例或作用域單例。對于無狀態(tài)的服務(wù)比如日志服務(wù)、配置服務(wù)直接注冊成InSingletonScope()。這樣整個(gè)程序生命周期內(nèi)只創(chuàng)建一次實(shí)例解析速度會非?？?。有狀態(tài)的組件要特別小心比如用戶會話、設(shè)備臨時(shí)狀態(tài)這些絕對不能共用單例要堅(jiān)持用瞬態(tài)或獨(dú)立實(shí)例。判斷生命周期的方式很簡單對象里如果只有配置數(shù)據(jù)和方法邏輯可以單例如果字段里保存了可變狀態(tài)就必須瞬態(tài)或獨(dú)立作用域。第三層面是在容器層面減少動(dòng)態(tài)解析。Ninject 在解析時(shí)需要通過反射查找構(gòu)造函數(shù)和綁定信息這個(gè)開銷雖然不大但高頻解析仍然會積累。我一般在設(shè)備驅(qū)動(dòng)的讀取鏈路上完全避免容器調(diào)用——驅(qū)動(dòng)對象在工廠里創(chuàng)建時(shí)是走容器的但創(chuàng)建完成后的數(shù)據(jù)讀寫循環(huán)則直接調(diào)用驅(qū)動(dòng)實(shí)例的方法不經(jīng)過任何容器。有人可能會問既然性能敏感場景下還要繞開容器那依賴注入的意義在哪里我的理解是依賴注入的價(jià)值不在調(diào)用鏈上而在系統(tǒng)組裝和擴(kuò)展的靈活性上。它讓系統(tǒng)的“靜態(tài)結(jié)構(gòu)”變得可配置、可插拔而運(yùn)行時(shí)的高頻路徑依然保持直接調(diào)用。這兩者并不矛盾關(guān)鍵是找到合適的邊界。在多場景適配方面這套基于 Ninject 的框架在我不同的項(xiàng)目里都發(fā)揮了作用。除了最典型的多設(shè)備驅(qū)動(dòng)場景在以下三類場景中它也表現(xiàn)得很好。一是仿真與實(shí)機(jī)切換。工業(yè)項(xiàng)目經(jīng)常需要先做仿真調(diào)試再在實(shí)際設(shè)備上跑。我可以在開發(fā)模式下把設(shè)備驅(qū)動(dòng)綁定到一個(gè)SimulatedDriver仿真驅(qū)動(dòng)它返回預(yù)置的模擬數(shù)據(jù)到了現(xiàn)場再把配置切換成真實(shí)驅(qū)動(dòng)。因?yàn)榻壎嗤?、接口相同業(yè)務(wù)層代碼完全不需要區(qū)分“現(xiàn)在連的是真設(shè)備還是仿真設(shè)備”。二是多語言/多協(xié)議適配。同一套上位機(jī)軟件要賣給不同客戶有的客戶用西門子有的用羅克韋爾有的用國產(chǎn)PLC。通過配置文件的設(shè)備類型字段切換綁定一套代碼搞定所有客戶。這在商務(wù)上的價(jià)值很大——定制開發(fā)變成了可選配置。三是測試與 Mock 注入。單元測試時(shí)我們可以輕松地把設(shè)備驅(qū)動(dòng)替換成 mock 實(shí)現(xiàn)或者把數(shù)據(jù)庫服務(wù)替換成內(nèi)存版本。因?yàn)橐蕾囮P(guān)系全部通過構(gòu)造函數(shù)注入測試代碼里只需要構(gòu)建一個(gè)測試用容器注冊上需要的 mock 類型就能把被測模塊隔離出來。這在傳統(tǒng)“到處 new”的代碼結(jié)構(gòu)里幾乎不可能做到。9. 最后再說幾句實(shí)在話整個(gè)框架設(shè)計(jì)下來我覺得最難的部分不是代碼怎么寫而是團(tuán)隊(duì)是否真的理解了為什么需要這樣設(shè)計(jì)。依賴注入不是一個(gè)“導(dǎo)入一個(gè) NuGet 包、加幾行代碼”就完事的操作它本質(zhì)上是一種系統(tǒng)架構(gòu)層面的思維轉(zhuǎn)變。剛開始團(tuán)隊(duì)里有人不適應(yīng)覺得“我明明直接 new 一個(gè)對象就能用干嘛非要在配置文件里繞一圈”。直到遇到客戶臨時(shí)改設(shè)備、現(xiàn)場協(xié)議不統(tǒng)一、需求頻繁迭代這些真實(shí)痛點(diǎn)之后大家才真正理解了這套設(shè)計(jì)的價(jià)值。我個(gè)人在實(shí)際操作中的體會是不要等到架構(gòu)腐化了再重構(gòu)。如果你正在做一個(gè)工業(yè)自動(dòng)化項(xiàng)目而且開始感覺到“改一個(gè)功能要?jiǎng)雍芏辔募薄靶略鲈O(shè)備類型很痛苦”“測試很難寫”那就是該引入依賴注入框架的信號。不用追求一步到位可以從設(shè)備驅(qū)動(dòng)這一層開始試點(diǎn)先把設(shè)備抽象出來再用容器管理設(shè)備實(shí)例嘗到甜頭之后再逐步推廣到服務(wù)層、界面層。最后再分享一個(gè)小技巧配置文件不要做成靜態(tài) JSON 文件就完事了。我們最終在項(xiàng)目里做了一套“配置熱更新”機(jī)制——當(dāng)設(shè)備配置文件被修改后觸發(fā)一個(gè)配置變更事件工廠會自動(dòng)對比新舊配置對新增設(shè)備調(diào)用CreateDevice對刪除設(shè)備調(diào)用RemoveDevice對參數(shù)變更的設(shè)備做重連。這樣現(xiàn)場工程師調(diào)整設(shè)備參數(shù)時(shí)完全不需要重啟軟件。當(dāng)然這個(gè)機(jī)制要做好異常處理和沖突校驗(yàn)否則配置改錯(cuò)了會導(dǎo)致設(shè)備連接出問題。這套機(jī)制的具體實(shí)現(xiàn)代碼文本里不太好完整展開但核心思路就是在設(shè)備工廠里維護(hù)配置的“版本號”監(jiān)聽文件變化變化后走一次“增量應(yīng)用”流程。如果你正在構(gòu)建自己的工業(yè)自動(dòng)化軟件或者正在為“設(shè)備驅(qū)動(dòng)一換就要改代碼”頭疼我希望這篇文章能給你足夠的參考和信心。依賴注入不是互聯(lián)網(wǎng)大廠專屬的玩具在工控軟件里它同樣值得作為核心架構(gòu)的一部分來認(rèn)真設(shè)計(jì)和實(shí)踐。