5

アプリケーションを構築する方法について、フィードバック/ヘルプが必要でした。私の現在のソリューション構造は次のようになります。

  • UI (実際の MVC アプリケーション)
  • コア (コントローラーとビューモデルのみ)
  • サービス
  • BLL
  • データ (ドメイン オブジェクトにマップされたエンティティ フレームワーク DbContext)
  • ドメイン (単純な POCO オブジェクト)
  • インターフェース

他のもの

  • DbContext を Controller に注入するための Ninject (リクエストごと)
  • Domain オブジェクトを ViewModel にマップする AutoMapper

すべてのアセンブリには、Interfaces プロジェクトへの参照があります。これは、名前が示すように、単純なインターフェイス (つまり、IDbContext、IRepository など) にすぎません。

Services プロジェクトは、他のすべてのものを「結びつける」ものです。これは、データ アクセス層 (Entity Framework) への直接参照を持つ唯一のアセンブリです。

以下にいくつかのコードを提供しました。

コントローラーの例は次のようになります。

namespace Core.Controllers
{
    public class HomeController : Controller
    {
        private IDbContext dbContext;

        public HomeController(IDbContext dbContext)
        {
            this.dbContext = dbContext;
        }

        public ActionResult Users()
        {
            UserService userService = new UserService(dbContext);
            var users = userService.GetAllUsers();
            return View(Mapper.Map<IEnumerable<UserListViewModel>>(users));
        }
        ...

UserService クラス:

namespace Services
{
    public class UserService
    {
        private readonly IDbContext dbContext;

        public UserService(IDbContext dbContext)
        {
            this.dbContext = dbContext;
        }

        public IEnumerable<User> GetAllUsers()
        {
            IRepository<User> userRepository = new Repository<User>(dbContext);
            UserBLL userBLL = new UserBLL(userRepository);
            return userBLL.GetAllUsers();
        }
        ...

最後に、ビジネス層クラス:

namespace BLL
{
    public class UserBLL
    {
        private readonly IRepository<User> userRepository;

        public UserBLL(IRepository<User> userRepository)
        {
            this.userRepository = userRepository;
        }

        public IEnumerable<User> GetAllUsers()
        {
            return userRepository.Get();
        }
        ...

フィードバックや改善方法を探しています。基本的なタスクについては、サービス層のメソッドがビジネス層のメソッドとまったく同じになることに気付きました (つまり、「パススルー」機能)。私が望んでいるのは、この抽象化が、複数のビジネス層メソッドの呼び出しを必要とする可能性のあるより複雑なタスクに役立つことです。サービス層にビジネス ロジックを含めたほうがよいのでしょうか。

4

4 に答える 4

9

一見すると、サービスとコントローラー/コアレイヤーにこの方法でdbコンテキストを注入する必要はないと思います。それらは実際には直接それに依存しておらず、この方法でそれを行うと、理想的ではない結合が発生します。コアレイヤーにはユーザーサービスが注入され、ユーザーサービスとBLLにはリポジトリが注入されている必要があります。リポジトリには、DIフレームワークによって注入されたdbcontextがあり、依存関係として渡されてはなりません。

于 2012-08-22T20:14:17.020 に答える
1

これをチェックしてください: http://www.primaryobjects.com/CMS/Article122.aspx EF リポジトリ パターン + 作業単位パターン。他のレイヤーに関しては、アプリケーションとそれが何を達成する必要があるかによって異なります。あなたがやろうとしていることの詳細を教えてください。

于 2012-08-22T20:18:25.173 に答える
0

プロジェクトの編成とレイヤーの設計の改善の一部は、ドメイン オブジェクトを正しくすることに集中することで実現できます。

ドメインとして単純なPOCOオブジェクトがあると言いましたが、ドメインオブジェクトはビジネスのすべての「状態と動作」を持つオブジェクトでなければなりません。つまり、BLL アセンブリとドメイン アセンブリを分離する必要はありません。ドメイン オブジェクトが定義されると、EF を使用してコンテキスト クラスとエンティティ クラスを作成できます (これらは、ドメイン オブジェクトと比較して追加の動作がない限りドメイン クラスではありませんが、それらを異なるものにしておくと、将来の要件に役立つ可能性があります)。

その他のマイナーなポイントは、ドメインとサービスのレイヤー内にインターフェイスを分散させることは、各レイヤーを分離して理解するという点で優れていると思います。

于 2016-02-28T06:55:26.733 に答える