組み込みソフトウェアプロジェクト間で永続性ロジック、ユーザーインターフェイスロジック、ビジネスロジックを切り離して再利用する方法

Question

私はソフトウェアエンジニアとして組み込み機器ビジネスに5年以上携わっています。ほとんどの場合、当社のハードウェアメーカーは、リファレンスボード用のソフトウェア開発キットを提供しています。それらは主にLinux組み込みデバイスです。

問題は、ほとんどの場合、管理インターフェイス（Web UI、CLI、SNMP ...）が永続的なデバイス構成を格納するデータベースと緊密に結合されており、インターフェイスが適用するすべての操作を独自に実行することです。システムへの新しい設定。たとえば、ユーザーがWeb UIを介してファイアウォールの状態を更新すると、Webサーバーはiptablesルールを引数として使用してCのsystem（）関数呼び出しを実行します。それは私たちを非常に非生産的にします：

粘着性のある部品を新製品に再利用することはできません。新製品の仕様はますます厳しくなり、組み込みシステムの開発にはコストがかかります。
管理インターフェイスは一貫しておらず、コードはそれらの間で繰り返されます。
コードは緊密に結合されており、抽象化が悪いため、同じことがタスクにも当てはまります。新しい機能の開発者がWebサーバーについて知っている必要がある場合、またはWebサーバーの保守担当者が機能の実装の詳細について知っている必要がある場合、タスクを並列化することは困難です。
コンポーネントをテストすることはできませんが、システム全体をテストすることはできます。

管理インターフェイスは、データベースAPIを呼び出して新しい設定を保存し、その後、データベースから新しい機能設定を読み取り、システムに新しい設定を適用する同じ関数を呼び出す場合があります。まだ良い解決策ではないと思いますが、このデザインについての意見を聞きたいと思います。

現在、ソフトウェアを、新製品で再利用できる責任あるコンポーネントに分割しようとしています。たとえば、現在の組み込みデバイスサービスを新製品で使用したいのですが、新しい仕様に簡単に適応できるユーザーインターフェイスも必要です。

ソフトウェアエンジニアとして、私はソフトウェアデザインにおける抽象化の悪さ、凝集度の低さ、カプセル化の悪さの結果を認識していますが、デザインパターンの背景がよくありません。これが私たちの計画です：

ユーザーインターフェイスから呼び出すことができるデバイスサービス用のC関数のセットを構築し、サービスの使用からすべての可能な実装の詳細を隠すインターフェイスを公開しました。システム時刻の変更、GPIOの管理、ファイアウォールの状態の変更などの機能があります。
このサービスAPIは、永続性レイヤーのAPIを使用して、データの永続性を処理します。
ユーザーインターフェイスは、このAPIサービスの関数セットを使用して新しい設定を取得および設定します。
サービスの各APIはx_initialize（）関数を公開するため、システムが起動すると、スタートアップマネージャーアプリケーションはサービスごとにこの関数を呼び出すことができます。この関数は、データベースからサービスの設定を取得し、独自のサービスAPIの他の関数を呼び出すことによってそれらをシステムに適用します。

上記のポイント4は、ユーザーインターフェイスがデータベースに新しい設定を保存し、大きな関数を呼び出す現在の状況とほとんど同じように見えるため、あまり好きではありません。実装の詳細が表示されるまで、この関数の機能は誰にもわかりません（関数の実装の詳細を見るのは私にとって悪い症状です）。

再利用するデザインパターンに関する情報を探しており、永続レイヤー、ユーザーインターフェイス、ビジネスオブジェクトまたはドメインオブジェクトのロジックとして関心の分離を行っています（ドメインオブジェクトとして適切な概念を使用しているかどうかはよくわかりません）。具体的な例を挙げて説明をお願いします。

Erik Eidt · Accepted Answer

探しているのは、ターゲットオペレーティングシステムで実行されるMVCスタイルのフレームワークです。 https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

パターンは非常に古く、多くのバリエーションがあり、フレームワークは絶えず進化し、新しいものが開発されています。したがって、私がやろうとしているのは、少し一般化することだけです。MVCのモデルには、ビジネス/ドメインロジックで保護された永続データがあり（つまり、間違ったものを保存できないようにする必要があります）、ビューはさまざまなモデル要素のレンダリングを処理しますuiに接続し、コントローラーは、uiコントロールからモデル（変更の要求）および/またはビュー（ビューの変更を要求するコマンドなど）へのコマンドのバインドと転送を処理します。優れたMVCフレームワークを使用すると、より高いレベルでの作業が容易になるため、配管工事を繰り返す必要がなくなります。

前述したように、MVCパターンはかなり古く、UIベースのデスクトップアプリケーションの開発をサポートするために最初に開発されました。そのため、今日のように永続性を直接説明していませんでした（つまり、すべての変更が自動的に永続化されます。代わりに、ユーザーがファイルを開いて後で保存することを期待していました）。モデルを永続性指向の部分とビジネスロジック指向の部分に分離することは賢明です（たとえば、ぶら下がっている参照がないことを保証し、データモデルの他の要件を強制します）。

（また、データベースを使用しているので、ORMを調べて、永続性と永続性のオブジェクトへのマッピングを支援し、また元に戻すことができます。）

あなたは間違いなく正しい質問をしているので、さまざまなプロジェクトで使用できる一般的な抽象化を探し続けてください。コードがNiceを読み取るだけの場合、私はそれが大好きです。なぜなら、それは高レベルであり、適切な抽象化を使用しているためです。これにより、多くの場合、深く掘り下げる必要がなくなります。うまく階層化されたコードは、操作が非常に簡単です。アイデアは、より高いレベルのAPIを導入してレイヤーを作成し、その上のレイヤーがそれを使用する場合、そのレイヤーが次の下位レイヤーに到達したりバイパスしたりして、さらに下位のレイヤーと通信しないようにすることです。それが得られれば、すべてがおそらくモジュール式であるが同じレベルである場合よりもはるかに多くのコード行を管理できます。

私はLinuxMVCまたはORMフレームワークについてあまり最新ではありませんが、これはあなたが探すべき場所だと思います。