标签: domain-model

将视图模型与域模型混合是否合理？

所以即视图模型对象包含一些域模型对象(不是相反的方式!)

我试图将我的DAL与我的业务层分开,在这样做的时候,我决定避开任何ActiveRecord方法并采用DataMapper方法.换句话说,我的域对象不会保持自己的持久性.在这样做的过程中,我似乎正在蚕食"贫血领域模式"的反模式.例如,我的计划中的一个实体是一个组织.

组织代表如下:

class Organization {
    private $orgId;
    private $orgName;

    // getters and setters
}

因此,基本上这个组织除了作为"包"(如马丁福勒所说)的一些数据之外什么都不做.在PHP世界中,它只不过是一个美化的数组.与之相关的行为为零.

在程序中的行为,我一直坚持像"组织服务"这样的"服务级"类,它主要作为这些对象和DAL之间的中介.

除了PHP的潜在扩展问题(我还有其他原因,我坚持在这些对象中"装袋"我的数据),这种方法是完全关闭的吗？

在这些情况下,您如何处理域模型？也许组织首先不属于我的域名？

我来自OO背景(C#,javascript),而Scala是我第一次涉足FP.

由于我的背景,我无法很好地实现适合我的域问题的域模型,并且还符合FP的良好实践,例如代码中的最小可变性.

首先,简要描述我现在的域名问题.

• 主域对象是: Event, Tournament, User, and Team
• Teams 由...组成 Users
• 双方Teams并Users可以参加Tournaments这发生在一个Event
• Events由Users和组成Tournaments
• 结果,统计数据,以及排名Teams和Users谁竞争,跨越Tournaments和Events将是一大特色.

鉴于问题的这种描述,我对域的最初想法是创建对象,其中双向循环关系是常态 - 类似于图形.我的想法是,能够访问任何给定对象的所有关联对象将为我提供最简单的路径,为我的数据编程视图,并操纵它.

case class User(
           email: String,
           teams: List[TeamUser],
           events: List[EventUser],
           tournaments: List[TournamentUser]) {
}
case class TournamentUser(
                     tournament: Tournament, 
                     user: User, 
                     isPresent: Boolean){
}
case class Tournament(
                 game: Game,
                 event: Event, 
                 users: List[TournamentUser], 
                 teams: List[TournamentTeam]) {
}

然而,随着我进一步深入FP最佳实践,我发现我的思维过程与FP原则不相容.循环引用是不受欢迎的,似乎几乎不可能与不可变对象.

鉴于此,我现在正在努力解决如何重构我的域以满足良好FP的要求,同时仍然保持域中"真实世界对象"的常识组织.

我考虑过的一些选择

• 使用lazy …

我对一些令我困惑多年的术语有疑问,我似乎无法弄明白.维基百科倾向于非常正式地解释这些事情,这对我来说很难理解......

我一直在努力理解的术语是:问题域,概念模型,领域模型,业务模型,业务领域,业务逻辑,领域逻辑等等.他们中的一些意思是一样的,有的则是交替使用,一些它们在不同的环境中意味着不同的东西.我要求的是高级概述,所以我不会对这些术语感到困惑......

这些术语是否都是域驱动设计的一部分？OO说话吗？我应该在什么情况下放置它们？

这是我到目前为止所理解的:

• 域是主题(即您正在建模的世界),模型试图简洁地解释概念/主题.
• 因此,域模型(=概念模型)试图简洁地解释域.
• 因此,业务模型可以解释业务的作用,因此业务与域名相同,除了域名更广泛,它不仅限于业务.

我在ER建模方面有一些经验,我从维基百科了解到,ER模型是用于表示概念模型(领域模型)的众多技术之一.

我可能完全错了,但它应该告诉你我的困惑在哪里......

哪个是Web开发,贫血域模型或富域模型的更好实践？

贫血域模型意味着实体是映射到某些持久存储的愚蠢POJO.getter和setter不验证状态转换,但信任上面的层.服务层负责验证实体的合法状态,并在违反业务规则时发出错误.这就是我习惯使用Spring和Hibernate构建Web应用程序的方法.

富域模型意味着验证逻辑(业务规则)驻留在实体本身中,例如,如果尝试非法状态转换,则从setter抛出异常.

在给出更深入的洞察之后,富域模型更接近于OOP原则,其中贫血域模型与将结构传递给C函数一样程序化(实际上,setter和getter在这里只是一个样板,以纪念javabean契约) .那么为什么更多采用贫血领域模型,这两种方法的优缺点是什么？

我可以看到富域模型的一些问题.例如,如果实体的有效状态取决于某些其他实体的状态,但实体没有对所有实体的引用,那么我们如何从实体内部验证状态？我们可以从setter访问数据库,但这会将持久性机制泄露给业务逻辑,这确实是一个非常糟糕的设计.此外,当ORM从数据库加载已经验证的对象并设置其值时,将执行不必要的验证!借助驻留在服务层中的业务逻辑,随着需求的变化,更容易添加临时验证逻辑,并使域模型保持清洁基础架构代码.实际上在任何一种情况下都是业务逻辑IS与持久性相关联,并且在实践中,域模型在没有逻辑的情况下毫无价值,但是当逻辑驻留在服务中时,我们可以将不同的规则集应用于不同上下文中的相同实体.我认为这是服务层的目的吗？

此外,hibernate或其他持久性机制期望实体是POJO,并且只对获取和设置值感兴趣.当然,富域模型数据库应始终处于一致状态,但如果不是,会发生什么？富域模型对现代ORM框架有何影响？

当我最近读到贫血领域模型是反模式时,我问了这个问题.我感到困惑,并希望听到这样一个声明的理由.

不久前,我与同事讨论了域模型的持久性以及是否应该在数据库级别强制执行外键约束.

我的第一反应是关系数据库的使用意味着强制执行这些约束,但有些人认为数据库应该只被视为持久性机制,因此我们应该避免在其中放置任何业务逻辑.我们最终没有使用外键约束.

这是我的问题(我希望它不太通用):在这些案例中强制执行关键约束是否被视为良好做法？

我在最新的ASP.NET MVC 3项目中使用实体框架.由于它是DB优先,实体框架生成数据库模型.在我的服务(业务)层I Scaffold(MvcScaffolding)中生成服务方法,视图和控制器.脚手架还会生成域模型.将这些模型绑定到视图时,我使用视图模型.

简而言之,我最终使用了三种类型的模型.这个可以吗？视图模型保存在表示层中,域模型保存在业务层中,数据模型保存在存储库层中.

请让我知道你的想法.

以下哪种方法被认为是在用户会话期间将数据存储在grails中的推荐方法？

1. 在实际会话中存储一堆单个变量.
2. 在会话中存储域模型类对象.
3. 使用会话范围控制器并将变量存储为控制器字段或属性.
4. 使用会话范围控制器并将数据存储为存储在控制器中的域模型类对象.
5. 我尚未想到的其他一些方式.

我很难确定给定模型中的哪个域可以被视为“核心域”。这可能很棘手，特别是如果有几个域是企业功能的核心。

我希望有人概述一个系统的过程，以便在处理具有多个候选对象的系统时挑选出核心领域。

我Entity Framework Code First在我的MVC应用程序中使用方法,并且我为数据库中的每个表都有一些实体类.另一方面,我需要使用一些查找值,即性别,状态,我不想创建单独的域模型或表,因此我需要enum在相关的域模型类或单独的类中定义值.虽然有在网络上许多样品,我还没有找到一个合适的EF和MVC.您能否提供满足此要求的示例用法？

注意:我用MVC5和EF6.这是我的实体类调用Visitor和示例实体,可以在单独的类(.cs文件)或同一类(.cs文件)中定义:

namespace MyProject.Entities
{
    public class Visitor
    {
        [Key]
        public int VisitorID { get; set; }

        public string VisitorName { get; set; }

        //[ForeignKey("ReasonOfVisit")]
        public byte ReasonOfVisit { get; set; }

        //code omitted for brevity
    }


    public enum ReasonOfVisit
    {
        NotSet = 0,
        Business meeting = 1,
        Periodic visit = 2,
        Getting information = 3,
        Leaving package = 4
    } …