0

C# ASP .NET MVC 4.0

私は MVC パターンを理解していますが、モデルになると:

public class User
{
    int id { get; set }
    int name { get; set; }
}

ビジネス ロジックをリポジトリ ( data fetchers ) から分割することには利点があることがわかりました。何かのようなもの：

public class UserRepository
{
    IEnumerableList<User> GetAllUsers()
    {
        IEnumerableList<Product> users = //LINQ or entity;
        return IEnumerableList<Product> users;  
    }  

    int GetScoreByUserId( id )          
    {
        int score = //LINQ or entity;
        return score;  
    }  
}

ビジネス ロジックは次のように User クラスに入りますか。

public class User
{
    public int id { get; set }
    public int name { get; set; }

    public bool HasDiscount( int id )
    {
        if( GetScoreByUserId( id ) > 5 )
            return true;
        return false;
    }
}

誰もまともな例を持っていますか。私にとって、そのような明確な例を見つけるのは 1 2 3 ほど簡単ではありません。

上記のコードは大丈夫ですか？リポジトリはユーザーを拡張する必要がありますか、それとも別のクラスにする必要がありますか..または、これらすべてをユーザークラス自体に入れる必要がありますか?

編集::---- それで、このようなものですか？

public class UserBusinessLogic
{
    public bool HasDiscount( int id )
    {
        if( GetScoreByUserId( id ) > 5 )
            return true;
    }
}

編集::----私が今これをどのように理解しているかの明確化

ここに画像の説明を入力

4

2 に答える 2

3

あなたの状況にはいくつかのオプションがあります。それらについては、たとえば、Martin Fowler著「Patterns of Enterprise Application Architecture」などの本に記載されています。したがって、選択するアーキテクチャ パターンによって異なります。

解決策を見つけようとしているとき、実際にはドメイン モデルパターン (関連するビジネス ロジック用の User クラスとデータ アクセス用の別の UserRepository クラス) のようなものを作成します。

これらの責任を 1 つのクラス User (ビジネス ロジックとデータ アクセスの両方) に統合することもできるため、Active Record パターンになります。

しかし、それぞれのパターンにはそれぞれの長所と短所があります。OOP と適切な関心の分離につながるため、ドメイン モデルを使用する方が確実に優れていると思います。

于 2013-07-17T13:01:25.747 に答える
1

私はこのパターンに従って大成功を収めました: FooController -> FooTasks -> FooRepository.

それはこの賢い男によって私に示されました。

「コントローラーはモデルを FooTasks に渡します。これにより、モデルがビジネス オブジェクトに変換され、FooRepository に送られます。利点は、データのあらゆる種類の下位レベルの表現がコントローラーから適切に隠されていることです。コントローラーは、データが永続化されているときにデータがどのように見えるかを知る必要はありません。」

MVC アプリケーションで非常に役立ちました。

于 2013-07-17T13:06:26.687 に答える