0

私は e コマース Web サイトを持っており、自分のプロジェクトが非常に n 層/疎結合/高度に拡張可能であることが気に入っています。

このプロジェクトは、MVC 3、ドメイン ライブラリ、サービス ライブラリ、およびデータ アクセス ライブラリ (リポジトリ パターン) にあります。

ただし、店舗全体の一時的な割引などの大規模で一定のビジネス ルールの実装、および最小限の入金手数料の導入については慎重です。

4

1 に答える 1

1

私の見解では、許可されたデータの状態を処理するビジネス ルールはすべて、データベースに適用する必要があります。これには、有効な個々の値だけでなく、値間の有効な関係も含まれます。検証を処理する場合は、処理を処理するレイヤーに移動する必要があります。たとえば、特定の状態から別の特定の状態への遷移が許可されているかどうかは、おそらくデータベースには属していませんが、その次の層に属している可能性があります。

SQL で使用できるさまざまな制約とデータベース トリガーは、許可された状態に関するルールを適用するのに適しています。検証に複数の行またはテーブルが含まれる場合、トランザクションの分離レベルや明示的なロックについて心配する必要がある場合があります。これらはデータベースの機能です。

于 2012-05-15T12:09:45.450 に答える