Question

我有类似的东西

public class Adult
{
    public int AdultId { get; set; }
    public string Name { get; set; }

    public virtual IEnumerable<NicknamedKid> NicknamedKids { get; set; }
}

public class Child
{
    public int ChildId { get; set; }
    public string Name { get; set; }
}

public class NicknamedKid 
{
    public int AdultId { get; set; }
    public int ChildId { get; set; } 
    public string Nickname { get; set; }
}

我的问题是，如果我想为成人创建新的NicknamedKid并将其添加到NicknamedKid类的Adult或某些{ {1}}课程？而且，如果我将它添加到AdultRepository类，这是否意味着该类必须知道要添加它的Adult类？

我想我对模型应该了解数据层的程度感到困惑。我认为模型应该能够处理自己的图层，而不知道任何Repository或Repository，但我认为这不可取（或可能）？

Answer 1

我责怪微软。无论如何，这通常是一种安全的立场，但特别是在这里，他们确实破坏了术语。你有一个名为MVC的框架，显然足够模仿MVC的模式，它们为你的项目提供名为＆＃34; Models＆＃34;，＆＃34; Views＆＃34;和＆＃34;控制器＆＃34;，足够恰当。他们搞砸了的地方是创建样本项目，他们填补了＃34;模型＆＃34; 实体的文件夹，不是模型。

如果您来自另一个MVC框架，例如Ruby on Rails或Django，您已经习惯了持久化模型的概念，也是该持久化数据的存储库。但是，微软没有采用MVC的方向，而是获得了一个实体，没有指导设置模型的内容或方式。自然的假设是，实体就是模型，正如你的情况那样，它只会造成混淆。

那么实体是什么？它本质上只是一个DTO，一个数据传输对象。它是数据库表的类表示，仅供实体框架填充它检索的数据。你的模特＆＃34;从MVC模式来看，实际上最终实际上是您的存储库/服务（DAL）和视图模型的合并，这些模型实际上比实体更接近模型的概念。

要回答您的问题，不，Adult不应该负责添加NicknamedKid，也不应该对实体框架或任何存储库有任何引用。它应该只保存持久化的数据和持久性所需的任何应用程序逻辑。

此外，只要我们在这里，NicknamedKid就不应该引用Adult，无论成人是否也应该知道NicknamedKid。 Adult引用了Child，即使您没有以这种方式设置它，但NicknamedKid实际上只是Child的子类。您基本上只是手动实现了Child和NicknamedKid之间的TPT（每种类型的表）继承，而实际上没有一个继承自另一个。 Nickname实际上只是特定类型的Child的属性（即，具有昵称的属性。但是，无论如何，您应该永远不会有一个实体与另外两个已经拥有的实体相比彼此的外键。如果你需要从NicknamedKid Adult获得，你可以通过Child来实现。不需要单独的关系。

代码优先 - 添加到相关的＆＃34;表＆＃34;在模型中？

1 个答案: