web-dev-qa-db-ja.com

ビジネスロジッククラスにあるべきもの

現在、ビジネスロジッククラスをどのように構成するかについて内部で議論しています。現時点では、ビジネスクラスを次のように構成しています。

public class OrderBL
{
    public void CreateOrder(OrderDTO order)
    {
        //save order
        //send email
    }

    public void CancelOrder(OrderDTO order)
    {
        //save order
        //send email
    }

    public void MarkOrderAsDispatched(OrderDTO order)
    {
        //save order
        //send email
    }

    //other private methods too
}

上記の現在の方法を使用すると、クラスが非常に急速に成長し、大きなプロジェクトで混乱する可能性があることがわかります。

ビジネスクラスを次のように変更する必要があるかどうかについては、いくつかの議論があります。

public class CreateOrderBL
{
    public void RunLogic(OrderDTO order)
    {
        CreateOrder();
        SendEmail();
    }

    private voide CreateOrder()
    {

    }

    private void SendEmail()
    {

    }
}

これを使用する利点は、クラスが理解しやすく、小さいことですが、欠点は、クラスの数が増えることです。

これに取り組む正しい方法は何ですか？

javac#design-patternsbusiness-logic
2
user1786107

「正しい」方法とは、保守性やパフォーマンスなどのアプリケーションの非機能要件を最も効果的に満たす方法です。

必要なのは、ビジネスロジックレイヤーまたは サービスレイヤー 。これらのレイヤーはCRUDメソッドを実際のビジネスオペレーションに変換します。はい、クラスは増えますが、これらのクラスは整理され、関心の分離が向上します。

Execute()スタイルのメソッドを大量に使用することは避けます。クラスをOrderProcessingやShippingなどのビジネスアグリゲートにグループ化し、ProcessOrder()（CreateOrderやSendEmailを呼び出す）などの意味のある名前をメソッドに付けます。

4
Robert Harvey

ビジネスオブジェクト指向モデルからへの移行を検討していますビジネスオペレーション/トランザクション指向モデル。多くのトランザクションシステムは、このようなアプローチに基づいて構築されています。

しかし、オブジェクト指向アプローチの利点をどのように維持しますか？課題は、注文の内部のどこかに追跡することです。そして、これらの内部の外部世界への可視性を制御します。

クラスが増えるだけでなく、ただし、クラス間、たとえばCreatOrderBLと、内部を維持し、最終的にオブジェクトの永続性を管理する必要がある一部のOrderBLとの間の相互作用も大幅に増加します。

結論：定義により、モデルの複雑さが増します。より単純なクラスの1つを理解するには、関連するすべてのクラスを十分に理解する必要があります。

0
Christophe

「正しい」は主観的であり、誰もが「正しい」が何を意味するかについて自分の考えを持っています。私の見解では、正しいとは、コードが機能し、保守と拡張が容易であることを意味します。私は、ワークフロー、アクション、エンティティを分離するデザインパターンを支持します。

この例では、「注文」はエンティティであり、アクションは注文（CRUD）で実行できるものであり、ワークフローは、アクションを調整してビジネス結果を達成するビジネスロジックです。理想的には、ビジネスロジックがエンティティを直接操作するのではなく、「アクション」レイヤーのみに依存します（それに応じてエンティティを操作する方法を知っています）。

その理由は、将来的には「注文」オブジェクトが変更されることを合理的に期待できるためです。たとえば、あるデータベースプラットフォームから別のデータベースプラットフォームに移行する場合があります。ビジネスロジックをエンティティオブジェクトから切り離すことで、ビジネスロジックレイヤーをオーバーホールすることなく、注文オブジェクトへの変更に対応できます。

同じ考え方に沿って、ビジネスロジックレイヤーが何にも触れず、常に「アダプター」レイヤーを通過するように設計するのが妥当です。たとえば、電子メールシステムが変更された場合、電子メールを送信するコードの一部を再検討する必要があります。

これらの理由により、私は最初の設計よりも2番目の設計を優先します。現在の（最上位の）設計では、注文システムや電子メール、永続化（データベース）のレイヤーが変更されると、それに応じてビジネスロジックの多くの場所が変更されます。これにより、変更に対応する際の柔軟性が妨げられ、ビジネス要件に応じてアプリを変更するために必要な複雑さが増します。

0
Thomas Carlisle