域对象,POCO和实体之间有什么区别?

jps*_*ook 73 c# architecture asp.net domain-driven-design

我觉得他们基本上都是一样的.模型对象也一样吗?

现在,在我的架构中,我有:

class Person 
{

    public string PersonId;        
    public string Name;
    public string Email;

    public static bool IsValidName() { /* logic here */ }
    public static bool IsValidEmail() { /* logic here */ }
}


class PersonService
{
    private PersonRepository pRepository;

    PersonService()
    {
        pRepository = new PersonRepository();
    }

    public bool IsExistingEmail(string email)
    {
        //calls repo method to see if email is in db
    }


    public Person GetPerson(email)
    {
        return pRepository.Get(email);
    }


    public void SavePerson(Person p)
    {
        if (Person.IsValidEmail(p.Email) && !IsExistingEmail(p.Email)
        {
            pRepository.Save(p);
        }
    }

}


class PersonRepository
{
    public void Save(Person p)
    {
        //save to db
    }

    public Person Get(string email)
    {
        //get from db
    }

    public bool IsExistingEmail(string email)
    {
        //see if email in db
    }

}
Run Code Online (Sandbox Code Playgroud)

所以这上面的类都是POCO,Domain Object,Model object,entity

ole*_*sii 95

我的(非标准)Layman定义

  • POCO - Plain Old%Insert_Your_Language%Object.一种没有逻辑的类型.它只是将数据存储在内存中.您通常只会看到自动属性,有时是字段和构造函数.
  • Domain object与您的域相关的类的实例.我可能会从域对象中排除任何卫星或实用程序对象,例如在大多数情况下,域对象不包括记录,格式化,序列化,加密等内容 - 除非您专门构建产品以进行日志,序列化,格式化或加密.
  • Model object我认为是一样的Domain object.人们倾向于互换地使用它(我可能是错的)
  • Entity 有一个班级 id
  • Repository从一方(例如数据库,数据服务或ORM)向服务,UI,业务层或任何其他请求主体讲述数据存储的类.它通常会隐藏所有与数据相关的东西(如复制,连接池,键约束,事务等),并使得处理数据变得简单
  • Service通常通过公共API提供某些功能的软件.根据层,它可以是例如RESTful自包含容器,或允许您查找所需类型的特定实例的类.

原始答案

这些术语主要用于(分布式)域驱动设计.他们不一样.术语模型对象可以用作域对象的同义词.

域对象.来自业务特定区域的对象,表示对域专家有意义的事物.域对象主要由实体和值对象表示.通常来说,生活在域层中的大多数对象都对模型有贡献,并且是域对象.

实体.从根本上定义的对象不是由其属性定义,而是由连续性和身份的线程定义.(意思是它必须Id)

POCO.一个没有复杂逻辑的简单对象,通常它只有一些属性,可以与ORM一起使用或作为数据传输对象使用

class Person- 实体和POCO,此类的实例是域对象
class PersonService- 服务
class PersonRepository- 存储库

  • 请参阅上面的代码示例,并告诉我您将如何应用这些条款. (4认同)
  • 为什么这种公然虚假的信息是最受欢迎和接受的。POJO 是 **NOT** 一种没有逻辑的类型。事实上,Martin Fowler 专门创造了术语 POJO 来与实体 Bean 进行对比(“我们指出了将业务逻辑编码到常规 Java 对象中而不是使用实体 Bean 的许多好处。”)。https://www.martinfowler.com/bliki/POJO.html (3认同)
  • 如果我的评论措辞强烈,我很抱歉,但同样,当术语的 *coiner* 定义 POJO 以明确包含业务逻辑时,您的个人经验并不重要。事实上,他会将你的实践归类在他认为是反模式的贫血域模型(https://martinfowler.com/bliki/AnemicDomainModel.html)下,他建议你改用 POJO。是否是反模式超出了这个定义的范围,但有一点很清楚:POJO **不** 意味着没有任何业务逻辑的对象。 (2认同)
  • @JohnPancoast 具有 setter/getter 且几乎没有其他内容的对象是数据传输对象 (DTO)。有时它是一个完整的 javabean。POJO/POCO 拒绝了这种框架性的废话,它试图让你相信,如果不继承普通对象的魔力,就无法解决它们的问题。当您编写一个好的 POJO 时,您甚至无法判断是否使用了框架。 (2认同)

Tej*_*ejs 18

它更多的是功能的内涵; 域对象是特定于逻辑实现的东西,可能比简单的POCO更复杂; 实体具有表示某事物的内涵(通常参考持久性媒介),而POCO只是一个类的快速标识符.模型只是用于表示对象的术语(通常包含状态,通常处理UI或DB).

并不是说有任何功能差异,它们只是用不同的术语来更接近地描述某些东西.喜欢赛车,卡车和家庭轿车之间的区别.所有都是汽车,但每个术语都更具描述性.


Bob*_*tor 15

基本上它归结为内部逻辑

  1. 域对象具有内部域逻辑,如验证等.
  2. 模型基本上是一个轻型域对象,他们知道他们拥有的数据,但没有真正关于它将如何使用
  3. 实体持有数据并具有一些内部知识,包括它的来源,以及它将保存,更新等的位置
  4. POCO持有数据并且可能拥有关于它自身的一些内部知识,例如属性集合中所有项目的总价值
  5. DTO是最简单的项目,它只保存数据并且没有逻辑

它们基本上都用于同一件事,它只是你想要它们多么聪明

根据您的代码示例Person类将是域对象或模型,另外2个是服务和存储库.使用域对象,Pocos,模型,dtos等,就像消息从一层传递到下一层一样,像PersonService这样的服务类是应用程序中的一个层,与Repository类一样,就像PersonRepository一样.为了一个好看的视图,看看http://bob-the-janitor.blogspot.com/2009/07/n-tier-design-revisit-part-1-over-view.html在这种情况下,它正在谈论使用一个基本上是dto的数据实体


k3b*_*k3b 11

在上面的答案中已经很好地解释了域和模型.

在数据库 - 上下文实体中表示实体关系模型ERD中的项.(即表中的一行)

Microsoft-Dotnet-EntityFramework中,World Entity表示可以使用数据(基础)上下文从数据库加载并保存到数据库的对象.通常,没有数据(基础)上下文,实体就不可能存在.(单位 - )测试这些类的业务功能是困难的.

Pocos(Plain Old CommonRuntime Objects)可以在没有PersistenceFramework(EntityFramework或NHibernate)的情况下存在,因此它们更容易测试.

poco这个词是由于同样的原因在java世界中创建的pojo(普通的旧java对象)适应性.