标签: repository-pattern

我创建了一个POCO模型类和一个处理持久性的存储库类.由于POCO无法访问存储库,因此存储库中有许多业务逻辑任务似乎不对.根据我的阅读,看起来我需要一个位于UI使用者和存储库层之间的服务层.我不确定的是它应该如何工作......

除了服务层,还应该有一个单独的业务逻辑层,还是那个服务层的角色？

每个存储库应该有一个服务吗？

服务层是UI可以实例化模型对象还是存储库为服务提供新模型实例的唯一方式？

我是否将我的参数,模型和其他验证放在服务层中进行检查以确保输入有效以及更新前数据库中是否存在要更新的项目？

模型,存储库和UI都可以调用服务层,还是仅供UI使用？

服务层应该是所有静态方法吗？

从UI调用服务层的典型方法是什么？

模型与服务层应该进行哪些验证？

以下是我现有图层的示例代码:

public class GiftCertificateModel
{
    public int GiftCerticiateId {get;set;}
    public string Code {get;set;}
    public decimal Amount {get;set;}
    public DateTime ExpirationDate {get;set;}

    public bool IsValidCode(){}
}


public class GiftCertificateRepository
{
    //only way to access database
    public GiftCertificateModel GetById(int GiftCertificateId) { }
    public List<GiftCertificateModel> GetMany() { }
    public void Save(GiftCertificateModel gc) { }
    public string GetNewUniqueCode() { //code has to be checked in db }

    public GiftCertificateModel CreateNew()
    {
        GiftCertificateModel gc = new …

我正在尝试学习域驱动设计(DDD),我认为我有了基本的想法.但是有些让我困惑的事情.

在DDD中,持久性模型和域模型是不同的东西？我的意思是,我们设计的域名和类只考虑了域名问题; 没关系.但在那之后,当我们构建我们的存储库或任何其他数据持久性系统时,我们是否应该创建另一个模型以在持久层中使用？

我在想我们的域模型也用于持久化,这意味着我们的存储库从查询返回我们的域对象.但今天,我读了这篇文章,我有点困惑:

刚刚停止!域模型不是持久性模型

如果这是真的,那么从域对象中获得单独的持久性对象会有什么好处？

我即将实现一个带有存储库和工作单元的Entity Framework 6设计.

有太多的文章,我不知道最好的建议是什么:例如我真的喜欢这里实现的模式:由于这里的文章建议的原因

但是,Tom Dykstra (Senior Programming Writer on Microsoft's Web Platform & Tools Content Team)建议它应该在另一篇文章中完成:这里

我订阅了Pluralsight,并且它在每次在课程中使用时都以稍微不同的方式实现,因此选择设计很困难.

有些人似乎认为工作单元已经DbContext在这篇文章中实现,所以我们根本不需要实现它.

我知道之前已经提出过这类问题,这可能是主观的,但我的问题是直接的:

我喜欢第一篇(Code Fizzle)文章中的方法,并想知道它是否可能更易于维护,并且可以像其他方法一样容易测试并且可以安全地继续使用？

任何其他观点都非常受欢迎.

我现在一直在使用MVC框架,我真的很喜欢这些问题是如何被分离出来的.我养成了让控制器完成相当多工作的坏习惯.所以我真的在寻找一些建议.

当我第一次开始使用MVC时,我常常让控制器在数据库工作完成后对模型进行操作.我知道这很糟糕所以将这项工作转移到模型中.但是我对此并不满意,因为我希望我的模型能够很好地学习.

我已经做了一些阅读,我看到人们通过提供服务层来保持他们的控制器和模型,我喜欢它的外观.

我只是想了解服务层和存储库应该如何协同工作.以下是我的假设,如果这是一种好的工作方式,请你告诉我吗？

1. 如果不需要对数据进行操作,则控制器可以直接调用存储库,因此服务层不需要涉及
2. 一旦需要对数据(业务逻辑)进行任何工作,那么这应该在服务层完成,并且控制器将在需要时对服务层进行简单调用.
3. 一旦服务完成了它的业务逻辑,它就会根据需要使用存储库(如果需要保留数据).
4. 理想情况下,模型应该保持精益,理想情况下,行动只不过是DTO
5. 数据验证将在模型中完成(使用MonoRail验证属性).我很感激甚至没有人喜欢用很多属性污染他们的模型,但这是一个不同的讨论.我喜欢MonoRail的验证属性,可以在UI中自动进行jQuery验证.

我试图将我的所有代码都转换为单一责任原则,因此试图理清我的编码实践.

谢谢

我知道这个问题被问了很多次,但没有一个答案对我有帮助.

我在Laravel 5中遇到了异常

BindingResolutionException in Container.php line 785:
Target [App\Contracts\CustomModelInterface] is not instantiable.

我没做过什么就做了:

• 注册App\Providers\AppRepositoryProvider的app.php供应商
• php artisan clear-compiled
• 如果我替换MyService中的存储库上的接口,一切都有效,但我觉得这是错误的(它应该由IoC容器处理吗？).

结构体:

app
  - Contracts
    - CustomModelInterface.php
  - Models
    - CustomModel.php
  - Repositories
    - CustomModelRepository.php
  - Providers
    - AppRepositoryProvider.php
  - Services
    - MyService.php

应用程序\合同\ CustomModelInterface.php

<?php namespace App\Contracts;

interface CustomModelInterface {
    public function get();
}

应用程序\库\ CustomModelRepository.php

<?php namespace App\Repositories;

use App\Contracts\CustomModelInterface;
use App\Models\CustomModel;

class CustomModelRepository implements CustomModelInterface {

    private $Model;

    public function __construct(CustomModel $model) {
        $this->Model = …

我觉得我在圈子里跑来跑去.我似乎无法决定使用LINQ to SQL正确的存储库模式.如果您熟悉Rob Conery的 MVC店面,您将看到他的实现将LINQ生成的模型与另一个类包装在一起,并将LINQ生成的模型简单地视为数据传输对象(DTO).它看起来像这样:

//Custom wrapper class.
namespace Data
{
    public class Customer
    {
         public int Id {get;set;}
         public string Name {get;set;}
         public IList<Address> Addresses {get;set;}
    }
}

//Linq-Generated Class - severly abbreviated
namespace SqlRepository
{
    public class Customer
    {
         public int Id {get;set;}
         public string Name {get;set;}
         public EntitySet<Address> {get;set;}
    }
}

//Customer Repository
namespace SqlRepository
{
    public class UserRepository : IUserRepository
    {
        private _db = new DB(); //This is the Linq-To-Sql …

我正在尝试使用VS2010使用EF4的存储库模式.

为此,我通过右键单击实体模型设计器并单击添加代码生成项来使用POCO代码生成.然后我选择POCO模板并获取我的课程.

我希望能够做的是将我的解决方案结构化为Entity(POCO)类的单独项目以及实体模型和存储库代码的另一个项目.

这意味着我的MVC项目可以将POCO类用于强类型视图等,而不必知道存储库或必须引用它.

要将它们全部插入,我将有另一个带接口的独立项目并使用IoC.

听起来不错我只是不知道如何将类生成到自己的项目中!我可以复制它们,然后更改它们的名称空间,但我想在每次更改数据库中的模式并希望更新我的模型时避免手动工作.

谢谢

我正在从SVN迁移到Git.在SVN中,我在一个SVN存储库中有多个eclipse项目,便于浏览项目.我打算在每个eclipse项目中使用一个git存储库,但EGit建议不这样做.

EGit指南建议将多个项目放入一个Git存储库中.

查看类似的问题,例如每个存储库建议一个项目.

哪种方法是最佳实践,人们实施什么？

(注意:我的问题与三个月前提出这个问题的人非常相似,但从未得到过回答.)

我最近开始使用MVC3 + Entity Framework,我一直在阅读最佳实践是使用存储库模式集中访问DAL.这也伴随着您希望将DAL与域(尤其是视图层)分开的解释.但是在示例中,我看到存储库(或似乎是)只是返回DAL实体,即在我的情况下,存储库将返回EF实体.

所以我的问题是,如果它只返回DAL实体,那么存储库有什么用呢？这是否会增加一层复杂性,而不会消除在层之间传递DAL实体的问题？如果存储库模式创建"进入DAL的单一入口点",那么它与上下文对象有何不同？如果存储库提供了一种检索和持久化DAL对象的机制,那么它与上下文对象有何不同？

此外,我至少读过一个地方,工作单元模式集中了存储库访问以管理数据上下文对象,但我不知道为什么这也很重要.

我98.8%肯定我在这里遗漏了一些东西,但从我的读数中我没有看到它.当然,我可能只是没有阅读正确的消息来源......:

我的存储库处理并为丰富的域模型提供持久性.我不想将贫血的Entity Framework数据实体暴露给我的业务层,所以我需要一些在它们之间进行映射的方法.

在大多数情况下,从数据实体构造域模型实例需要使用参数化构造函数和方法(因为它很丰富).它不像属性/字段匹配那么简单.AutoMapper可用于相反的情况(映射到数据实体),但不能用于创建域模型.

以下是我的存储库模式的核心.

在EntityFrameworkRepository类的工作有两个泛型类型:

• TDomainModel:丰富的域模型
• TEntityModel:实体框架数据实体

定义了两种抽象方法:

• ToDataEntity(TDomainModel):转换为数据实体(for Add()和Update()方法)
• ToDomainModel(TEntityModel):构建域模型(用于Find()方法).

这些方法的具体实现将定义所讨论的存储库所需的映射.

public interface IRepository<T> where T : DomainModel
{
    T Find(int id);
    void Add(T item);
    void Update(T item);
}

public abstract class EntityFrameworkRepository<TDomainModel, TEntityModel> : IRepository<TDomainModel>
    where TDomainModel : DomainModel
    where TEntityModel : EntityModel
{
    public EntityFrameworkRepository(IUnitOfWork unitOfWork)
    {
        // ...
    }

    public virtual TDomainModel Find(int id)
    {
        var entity = context.Set<TEntityModel>().Find(id);

        return ToDomainModel(entity);
    }

    public virtual void …