1

我用这种架构创建了一个应用程序：

  • 我的项目。型号：包含 POCO。例子：
public class Car
{
     public int Id { get; set; }
     public string Name { get; set; }
}
  • 我的项目。存储库：包含存储库和 UnitOfWork
public class UnitOfWork
{
    // ...
    public Repository<Car> Cars { get; set; }
    // ...
}

public class Repository<T>
{
    // ...
    // Add / Update / Delete ...
    // ...
}
  • 我的项目。网页：ASP.Net MVC 应用程序

现在我想找到一种使用方法与数据交互的方法。例如，在MyProject.Model.Car我想添加一个将获取具有非导航属性的数据的方法，一个名为“GetSimilarCars()”的方法。问题是存储库无法与其他存储库交互，因此无法对数据库执行操作。

我真的不知道如何以简单的方式做到这一点，以及在我的架构中放置它的最佳位置是什么。

另一个示例可能是UserGroup.Deactivate()，此方法将停用每个用户并通过电子邮件向他们发送通知。当然我可以把这个方法放在 Web 应用程序控制器中，但我认为这不是放置这种可以在应用程序的许多地方调用的代码的地方。

注意：我正在使用实体框架。

关于如何实施此类操作的任何建议？

4

3 回答 3

2

我假设您的业务层 (BL) 将与您的数据访问层 (DAL) 进行通信。这样，您就可以从您的 BL 访问 DAL 中的不同存储库。这将解决您的存储库无法共享数据的问题（该数据将通过 BL 共享）。

请参阅此处：带 EF 和 MVC 的 N 层架构

于 2013-11-04T22:36:59.317 回答
2

这种类型的东西进入你的 DAL（在这个有限的场景中，本质上是你的工作单元和存储库）。然而，当我第一次开始使用 MVC 时，这种模式让我很苦恼。Entity Framework已经实现了这些模式；你DbContext是你的工作单元，你DbSet是你的存储库。在此基础上创建另一个层只会增加复杂性。我个人最终选择了一种服务模式，它仅仅位于 EF 之上，并允许我执行 someService.GetAllFoo() 之类的操作。这样一来，Entity Framework 的使用就被抽象出来了（我可以随时切换 DAL。我什至可以完全删除数据库并使用 API，而无需更改应用程序其余部分的任何代码。）但我也不只是重新发明轮子。

在服务模式中，您专门只为您需要的东西提供端点，因此它是类似 的完美候选者GetSimilarCars，因为您只需向服务添加另一个方法来封装其逻辑。

于 2013-11-04T22:50:59.063 回答
0

我并没有完全让您提出问题，但这就是您分配值的方式。并将其添加到集合中

public class Repository<T>
    {       

    List<car> _lstCar=new List<car>();
    //Add
    car cobj=new car();
    cobj.Id="1234";
    cobj.Name="Mercedes";

    _lstCar.Add(cobj);

    }
于 2013-11-04T22:20:37.307 回答