いくつかの自動化を含むワークフローWebアプリを設計するためのアプローチ
私は、エンドユーザーにセルフヘルプワークフローを提供するWebアプリケーションを作成し、質問をして、最後に到達するまで応答に応じてワークフローの別の部分にスキップするという任務を負っています。
これは問題ありません。管理者が自分で新しいワークフローを作成して保存できるデータ駆動型アプリケーションの作成を検討していました。これは、次のDBテーブルに基づいています。
- カテゴリ
- ワークフロー
- ステップ
- 反応
ただし、これらのワークフローには、DBのどこかにある値、ユーザーのワークステーションのregキー値、Active Directory（ad inifinitum）のLDAP値をチェックするなど、自動チェックステップが含まれると言われています。既知の値/望ましい値（それ自体が動的な場合もあります）。これにより、すべてのワークフローをアプリケーションにハードコーディングする必要があるように見えるため、作業中にスパナが完全にスローされます。これは避けたいと思っていました。
アプリケーションを（ある程度）データ駆動型にし続けることを可能にする、私が見ていなかったこれにアプローチできる方法はありますか？または、これらのタイプのワークフローをアプリにハードコーディングすることはOK /標準ですか？顧客は定期的に新しいワークフローを追加したいと思うでしょう。
参考までに、私たちはMSショップなので、これをC＃で開発します。
ここで2つの可能な解決策を考えることができますが、どちらもかなりの量の開発が必要です（ただし、そうでない場合の解決策は実際にはわかりません）。実際に必要になるまで、特定の種類のチェックステップを開発することもしないことをお勧めします。 42種類の自動化されたステップの要件を設定するのは非常に簡単で、実際に使用されるのはそのうちの2つまたは3つだけです。
オプション1：ステップをハードコーディングする
ワークフローをハードコーディングする必要はありませんが、自動チェックステップをハードコーディングする必要があります。あなたの基本的な構造には複数の回答があるステップがあり、各回答は質問票に記入する人を新しいステップに送ると思いますよね？その場合、さまざまなタイプのステップを作成します。
- 基本的なステップは、ユーザーが自分で定義して追加できる可能な応答のリストと、ジャンプ先の関連ステップを含む「QuestionStep」です。
- 別のステップは 'DatabaseValueStep'であり、これによりユーザーは実行するクエリを入力し、返される値のリストを定義し、ジャンプ先の関連するステップを定義できます。
- もう1つのステップは、ユーザーがADプロパティを入力して、返される値のリストを確認および定義し、関連するステップにジャンプできるようにする「LDAPValueStep」です。
- .。
自動チェックステップの種類ごとに開発が必要です。
オプション2：アプリケーションのテーブルにデータをプッシュして確認する
データベースにインポートされるキーと値の動的システムを定義できます。キーは動的であり、データベースに追加できます。その後、アプリケーションでCheckStepで使用できるようになります。データを取得するには、他のシステムとこのシステムの間に統合を作成する必要がありますが、ワークフローアプリケーションからデータプロバイダーに作業をオフロードします。
たとえば、「personid」、「key」、および「value」列を持つPersonDataテーブルを作成できます。別のアプリケーションは、キー「BirthDate」を使用して行を追加することにより、テーブルに人々の生年月日を入力します。ワークフローアプリケーションのPersonCheckStepを使用すると、キー 'BirthDate'に対して実行する処理を定義し、データを取得する方法を知ることができます。これを拡張するには、PC設定用のComputerData、LDAP設定用のLDAPDataなどを使用します...
JDTの答えはかなり良いですが、検討したい別のオプションは ドメイン固有の言語 （DSL）です。このアプローチでは、ワークフローをキャプチャするための単純な言語を定義し、特殊なチェックやステップなどのプリミティブを提供してから、それらを解釈して実行するエンジンを作成します。
すべてをデータベースに保持するか、ハードコーディングすることで、システムを石灰化し、ワークフローにバリエーションを導入することを困難にします。言語を使用することにより、その言語が必要な豊富さを認めている場合、ワークフロースクリプトに複雑さをプッシュし、エンジンをクリーンで比較的単純に保ちます。
さらに特別なチェックとステップを追加することは、DSLに必要な特別な作業のためのC＃実装を提供するライブラリに似たもので処理できます。ここでも、メインワークフロー（DSLスクリプト内）を、チェックとステップ（ライブラリ内）から、それをすべて実行するエンジンから分離しています。複雑さを管理しやすくする必要があります。
例として、多くのビデオゲームには、ゲームエンジンによって解釈されるDSLで定義されたレベルがあります。は、強力なプログラミングスキルを持たない人々が生産性を発揮し、最も高価な開発者が特定の各レベルのすべての機能を実装することを必要とせずに価値あるものを作成できるようにします。
あなたが自問する必要があるのは、メンテナンス（将来のユーザー要求のためにコードを変更する必要がないこと）によって節約された労力または追加の多様性（簡単に変換してアプリを別のユーザーに売り込むことができるなど）が追加の価値があるかどうかです。より一般化されたシステムを作成する努力。誰かがあなたに塩を渡すように頼んだとき、普遍的な調味料調味料工場を書かないでください。
考慮すべきもう1つのオプションは、アーキテクチャがカスタマイズを処理できることを確認することですが、最初にハードコードされたバージョンを作成し、後で管理インターフェイスを作成することを心配します。