0

このシナリオは、MVCプレゼンテーション層にサービスを提供するサービス層を備えた3層アプリにあります。

たとえば、従業員のセット内で電子メールが一意である必要がある従業員を作成する操作があります。この操作は、サービスを介してMVCプレゼンテーション層で実行されます。

電子メールがすでに別の従業員のデータベースに登録されている従業員を作成する意図を管理するにはどうすればよいですか？

私は2つのオプションで考えています：

1）新しい従業員に同じ電子メールが送信された従業員がいるかどうかを照会する別の操作を行います。

2）重複した電子メールに対してサービスCreateEmployeeで例外をスローします。

それは私が問題に最も適している、または最も適していると思うものの問題だと思います。これは検証の問題だと思うので、1）オプションを提案します。ただし、2）オプションでは、サービスへの呼び出しが1回だけ必要であるため、（？）より効率的です。

どう思いますか？

ありがとう！

4

2 に答える 2

3

私は間違いなく2番目のオプションで行きます：

  • あなたが言ったように、それはサービスへの1回の呼び出しを避けます
  • 従業員を作成するための1つの方法だけで、サービスインターフェイスをクリーンに保ちます
  • トランザクションの観点からは一貫性があります（「トランザクションが失敗した」という意味の例外）。検証は、トランザクションを失敗させる可能性のある多くの理由の1つだけではないことに注意してください。
  • 検証の制約が進化することを想像してください（例：他の従業員の属性...）、これだけのためにすべての実装を進化させたくはありません。

留意点：失敗の原因を明確に特定できるように、例外を十分に冗長にするようにしてください。

于 2012-05-11T23:19:35.850 に答える
1

「プレゼンテーション」層が本当にプレゼンテーションを意味する場合は、その層に新しい従業員を作成するべきではありません。HTTP応答オブジェクトにきれいに表示されるデータのみを準備する必要があります。

一般に、この種の問題を考える良い方法は、コマンドラインプログラムによって呼び出された場合にサービスオブジェクトが何をすべきかを検討することです。

> createEmployee allison.brie@awesome.com
  Error! 'allison.brie@awesome.com' is already registered.

これには、サービスを呼び出す端末管理レイヤーがあります。このサービスは、同じ電子メールを持つ別のユーザーがいることを認識するために何かを実行し、適切な例外をスローします（つまりDuplicateUserException）。次に、端末管理レイヤーがその例外を解釈して出力します"Error! " + exception.getMessage();

そうは言っても、2つのオプションは実際には同じオプションであることに注意してください。サービスは引き続きデータベースに重複を照会する必要があります。これは「検証」ですが、入力検証ではありません。入力検証とは、それが有効なメールアドレスであるかどうかを確認することを意味します。（「@」記号と有効なTLDはありますか？）

于 2012-05-11T23:19:08.730 に答える