3

ERP システムのデータ アクセス方法を含む 1 つの DAL を持っています (または持つ予定です)。

ビジネス的には、この DAL を使用するコンテキストがあります。例: バーコード アプリケーション、カスタム販売ピッキング アプリケーション、注文書アプリケーション。

ビジネス層用に 1 つの DLL を作成する代わりに、これらの主要な領域に分割して、DAL と確実に通信できるようにすることを考えています。これにより、完成したアプリの肥大化を抑えることができます

これが私の最初の質問です。2 つ目は、すべての BL からアクセスできるようにするために、ビジネス レイヤー間で共通のデータ アクセス オブジェクトを別のプロジェクトに配置する必要があるということです。

最後に、これらのデータ アクセス オブジェクトは、多くのメソッドがこれらのオブジェクトのリストをビジネス レイヤーまたは直接プレゼンテーションに返すため (一般的ではありませんが、発生する可能性があります)、DAL にも役立ちます。それらは、DAO を持つ同じ共通クラスを参照する必要がありますか?

4

2 に答える 2

1

DAOとBLの両方が使用できるドメインオブジェクトを持つことができます。ドメインオブジェクトは非常にダムである必要があり、特定のエンティティの表現である必要があります。

例：

Bl.Get-employee-> Return Domain Object Employee

BL.Get-Employeeメソッドは、データマイニングをドメインオブジェクト（この場合はEmployeeドメインオブジェクト）に変換するDAOを呼び出します。

Bl.Get-employee>>DOA.Get-employeeを呼び出します。すべてのデータベース操作はDAOによって処理される必要があります。

ビジネスロジックがあるシナリオでは、コードは次のようになります。

Employee Bl.ProcessRecord(EmployeeDomain Employee)
{
    //Do some logic....
    //Perhaps interact with other DAO operations
    //Have some business logic operations ETC
    Persist your changes to the database
    Employee = DAO.Save-employee(Employee)
    return Employee;
}
于 2012-12-09T18:40:37.697 に答える
1

2 番目の質問に対する答えはかなり明確だと思います。DAL には独自のプロジェクトが必要です。

1 つ目に関しては、さまざまなアプリケーションのニーズの間にどれだけの共通性があるかによって異なります。また、複数の BLL DLL に分割すると、ビジネス ロジックのメンテナンスが複雑になるかどうかも考慮する必要があります。

同じ UI から DAL と BLL にアクセスするという最後の項目については注意が必要です。これは、両方に依存できることを意味します。UI から BLL、DAL へとすべてが移行するように、DAL 機能を呼び出して応答を返すだけのシンプルなメソッドを BLL に配置することをお勧めします。

もちろん、これらすべてを踏まえて、どの答えが自分のアプリケーションと開発方法論に最も適しているかを考える必要があります。

于 2012-12-09T11:53:21.077 に答える