私は初心者としてWindowsWorkflow4.5の技術的な詳細と実装を掘り下げており、まともな結果を得ています。私の質問は、「なぜ、いつ」という質問と「方法」の質問のどちらかということです。
私は私たち全員に馴染みのある概念を採用し、ビジネスロジックをWF、つまりユニバーサルログオンプロセスに抽象化しました。私が達成したかったのは、MVC WebサイトやWindowsフォームアプリケーションなどから呼び出すことができる再利用可能なロジックを持ち、すべてを同じワークフローで実行することであり、それを達成しました。
ここで、WFを「いつ」適用するかとコードをいつ使用するかについて2つの概念的な質問があります。
1-例として簡単な検証を取り上げます。ログインしようとしていますが、空のユーザー名またはパスワード文字列を渡しました。明らかに、私はエンドユーザーに「UserNameRequired」と「PasswordRequired」というメッセージを送り返したいと思っています。さて、私がそれをした方法は、検証クラス（重要な場合はFluentValidation NuGetパッケージ）を持っていることですが、重要なことは、これをコードで実行していることです。したがって、WFでは、ExecuteMethodを介して検証コードを呼び出し、すべてが正常に機能します。私の質問は：これはWFの考え方では間違ったアプローチですか？インラインWFの「If」アクション/決定を実行し、コードのチャンクを呼び出すのではなく、WF内で検証メッセージを直接構築する必要がありますか？私' 検証だけでなく、私たち全員が関係できる概念として、より一般的には、できることすべてをWF自体に入れようとするべきですか、それともカスタムコードを呼び出す方がよいでしょうか。私は、可能であれば誰かの意見ではなく、WFの経験を持つ経験豊富なソフトウェアアーキテクトからの推論によるベストプラクティスをもっと探しています。
2-別のマシンでワークフローを取得します。したがって、同じログインワークフローアクティビティの一部には、サービスメソッドの呼び出しが必要です。ワークフローがインターフェイスメソッド「AuthenticateUser」を持つILogOnServiceのInパラメーターを受け取るようにコードとワークフローを記述しました。私が渡している具体的な実装は、MVC4 Web Api postメソッドを非同期で呼び出して、標準のAsp.NetメンバーシップValidateUserを実行します。繰り返しますが、WFワークフロー内からこのWeb Api PostAsyncを呼び出す必要がありますか？もしそうなら、私のワークフローをAsp.Netメンバーシップと私の特定のサービスの選択に密接に結び付けないでください。ワークフローを特定のポイントに到達させてから、別のマシンでプロセスを再開する方法があるようです。たとえば、サービスが実行されている場所で、プロセスを続行しますが、私は
このテクノロジーのプロからいくつかのガイドラインとアイデアを探しているだけですが、私は最も有益な答えを選びます。