時間の経過とともに扱いにくくなったため、古いアプリケーションを更新/更新しようとしています。
このアプリケーションは、薬局での調剤プロセスを通じて処方箋を追跡します。調剤プロセスには、バーコード スキャナーを使用して記録される多数の「アクティビティ」が含まれます。
アプリケーションは現在、メイン UI 用の asp.net Web フォーム アプリケーションであり、バーコード スキャンを処理するメソッドを提供する asp.net asmx サービスを備えています。(バーコード スキャン クライアント アプリは .NET Windows フォーム アプリです)
Web サービス (メイン UI と同じ IIS Web サイトである asmx ファイル) は、データベース アクセスを最小限に抑えるために、アプリケーション オブジェクト内の「ライブ」の処方箋/ユーザー/アクティビティのコレクションを維持します。
メイン Web UI の MVC モデルに魅力を感じています。これにより、懸念事項が大幅に分離され、モバイル デバイスなどにビューを提供できるようになります。
少し確信が持てないのは、Web サービスを RESTful Web API サービスに移行する必要があるかどうかです。これは明らかに、MVC アプリケーションの設計に影響を与えます。現在の設定では、多くの作業を行うサービスがあります。つまり、スキャンを処理するためのすべてのロジックをカプセル化する「プロセス スキャン」のメイン メソッドがあります。たとえば、次のようになります。
- スキャンされたユーザー バーコード - サービスはこれをデバイス ID に対して保持します (デバイス ID がメソッドに渡されます)
-Prescription Barcode Scanned - サービスは、このデバイス ID のユーザー バーコードがあることを確認し、true の場合は処方 ID を保存します)
-アクティビティバーコードスキャン - サービスはユーザー/処方箋が完了していることを確認し、ユーザーがアクティビティを記録できることをチェックします。アクティビティが正しい場合は、スキャンシーケンスで正しいアクティビティであり、OK がアクティビティを記録した場合は、ユーザーの以前のアクティビティが必要かどうかをチェックします。などなど
RESTful 実装への移行は、これが次のエンドポイントを持つように分割されていることを示唆しているように思われます。
GET webservice/Users/USERID
GET webservice/Prescriptions/PRESID
POST webservice/Activities/ACTIVITYID
これは私がプロットを失い始めるところです-これは物事をより複雑にしているようで、POST部分は私を混乱させます. 与えられたすべての例は、1 つのリソース (注文や顧客など) を更新する明確なケースです。この場合、POST を使用するアクティビティを追加すると、他のアクティビティや処方箋に影響を与える可能性があります。次に、呼び出しをあまり密結合しないようにする必要があります。つまり、リクエストは、更新が必要なアクティビティ/処方箋の ID を返す必要があります。その後、追加の POST / PUT 呼び出しを呼び出してそれらを更新しますか? 単にロジックをクライアントに移しているだけではありませんか....
私はここでポイントを逃していますか? Web APIビットに飛び込んで、そこから残りを開発する必要があります....すでにこれを行っている人からのアドバイスは素晴らしいでしょう!
ありがとう