关于使用Code First，Repository Pattern和n-Tier的一些问题？

Question

我想先使用EF代码。我正在使用存储库模式。我想实现一个n层架构。我真正想要的是使用TDD，但我在聚合路由方面遇到了问题。我的问题是...

我有一个博客对象。可以从此博客对象添加关联的文件。太棒了。因此，我实际上有一个聚合根，我为它创建了我的存储库，然后我需要添加一些方法，允许我向博客‘添加’相关文件。但是我该把它放在哪里呢？这是一个数据访问层的东西，所以我真的希望它在那里。但老实说，这也是一个业务逻辑挑战。该产品的一部分是能够添加assoc文件。那么，我应该将添加Assoc文件的逻辑放在DAL还是BLL中？

希望有人能给我一些指导。

Answer 1

我认为你指的是DDD而不是TDD，因为你所说的在TDD的上下文中没有什么意义。

你需要坐下来思考一个文件对你的系统意味着什么，是否有任何连接文件和帖子的规则。例如，如果我们删除一个帖子，那么文件应该有什么用呢？我们也要删除它们吗？我们是否可以将同一文件“添加”到多个帖子。你坐下来，思考，收集关于你的文件的知识，然后你决定它是否值得在你的领域中引入一个地方。

一些我能想象到的示例领域：

public class Post
{
    private List<File> _files;
    public IEnumerable<File> AssociatedFiles {get {return _files;}}
    public void AssociateFile(File file){//...}
    public void DisassociateFile(File file ){//...}

    //It doesn't delete it just do some logic. Maybe we can't delete this post and need to throw exception or whatever logic you need
    public void Delete()
    {
        foreach (File file in AssociatedFiles) DisassociateFile(file);
    }
}

public class File 
{
    public String Url;
    public DateTime Created;
    public DateTime Modified;
}

public class PostRepository
{
    public void Delete(Post post)
    {
        post.Delete();
        DbContext<Post>.Delete(post); //I Don't remember EF syntax for this
        DbContext.SaveChanges();
    }
}

更新:让我们继续...

在对你的领域进行了5分钟的思考之后，我发现我最初的设计遗漏了重要的概念(一如既往地使用DDD，你会一点一点地获取知识)。

谁负责上传文件？用户可以关联他已经上传到帖子的文件，他可以添加新的文件(未上传)到帖子吗？他能把这些东西混在一起吗？这些都是重要的问题，同样，你需要考虑它并设计你的系统。

Answer 2

您正在谈论存储库和聚合根，所以我假设您是在说您想做DDD。在DDD中，您应该有一个域模型，它应该是您与系统用户一起开发的模型。在任何情况下，它都应该包含普通用户应该理解的概念。因此，如果用户认为博客具有关联的文件，并且可以将这些文件添加到博客中，则关联的文件属于您的域模型，并且您的博客对象应该具有add方法。我猜你的BLL就是你想要放那些相关文件的地方。

Answer 3

首先，在知道有界上下文之前，您无法标识聚合根。没有清晰的废话就没有AR。根据上下文，ANy对象可以是AR。我不知道你的域名，所以我认为博客添加文件所需的信息是有效的。因此，添加功能在AR中。

存储库处理与持久化相关的所有内容，即保存在数据库中。在这种情况下，它应该包含一个方法，不能少，也不能多。

public interface IBlogFilesRepository
 {
     void Save(Blog);
 }

您总是将域/业务逻辑放在域/BL层中。DAL只处理对数据库的保存/加载，它没有处理域行为的业务(原文如此)。