我已经阅读了福勒关于“贫血领域模型”的文章(链接: http://www.martinfowler.com/bliki/AnemicDomainModel.html),我同意他的观点.

我试图创建一个实体是简单POPO的应用程序,但是这样,我有一个胖服务层,而将一些逻辑放到实体中将是最简单的解决方案.

所以我会有这样的架构:

^
| Twig
| Controller | API
| Service
| Model
| Entity

哪里:

实体:将是简单的POPO,只是一袋二传手和吸气剂

模型:将是用业务逻辑装饰的实体对象

服务:包含涉及多个实体的所有业务逻辑(这里我也将放置验证任务),并且像转换器实体一样 – >模型

控制器| API:只匹配Request with Service,ParamConvert并检查autorization

Twig:表示层

我的问题是如何将实体层隐藏到控制器并且仅适用于模型.
为了用业务逻辑来装饰我的实体,我想构建一个使用存储库并装饰结果的服务(我找不到另一种方法来实现它).

所以,一个愚蠢的例子:

namespace ...\Entity\Article;
class Article {
    private $id;
    private $description;

    // getter and setter
}


namespace ...\Model\Article;
class Article {
    private $article; // all methods will be exposed in some way
    private $storeService; // all required services will be injected

    public function __construct($article,$storeService) {
       $this->article = $article;
       $this->storeService = $storeService;
    }

    public function getEntity() {
       return $this->article;
    }

    public function isAvailable() {
       return $storeService->checkAvailability($this->article);
    }

    ...
}


class ArticleService {
    private $storeService; // DI
    private $em; // DI
    private $repository; // Repository of entity class Article

    public function findById($id) {
       $article = $this->repository->findById($id);
       return new \Model\Article($article,$storeService);
    }

    public function save(\Model\Article $article) {
       $this->em->persist($article->getEntity());
    }
    ...
}

上层是以通常的方式制作的.
我知道这不是一个好的解决方案,但我找不到更好的方法来建立模型层.我真的不喜欢这样的东西:

$articleService->isAvailable($article);

而不是更多的OO:

$article->isAvailable();
我有DoctrineEntity对象扩展DomainModel对象.虽然控制器实际上可以接收DoctrineEntities,但它们只能在DomainModelInterface上运行.
... namespace DomainModel;
interface ArticleDomainModelInterface ...
interface ArticleDomainModelRepositoryInterface ... // create,find,save,commit
class ArticleDomainModel implements ArticleDomainModelInterface

... namespace Doctrine;
class ArticleDoctrineEntity extends ArticleDomainModel
class ArticleDoctrineRepository implements ArticleDomainModelRepositoryInterface

... namespace Memory;
// Usually dont need a memory article object
class ArticleMemoryRepository implements ArticleDomainModelRepositoryInterface

所有模型创建和持久性都通过存储库完成.控制器和其他相关服务仅知道ArticleDomainModel方法.这为您提供了良好的分离,并允许使用不同的存储库进行测试或支持不同的持久性机制.它还允许在域模型中使用值对象,同时仍然使用Doctrine 2持久化它们.

但是,在PHP中,我确实很难理解在域模型对象本身中实际可以放置什么样的有用业务逻辑.我倾向于最终得到服务中的大部分逻辑.这是因为我的大多数程序都是面向严重的.

还有一个问题:控制器本身是否可以访问域模型对象?

Doctrine 2的主要开发人员之一,Benjamin Eberlei,有很多关于这个主题的博客文章.他的所有文章都值得详细阅读.这里有一些:

http://www.whitewashing.de/2013/07/24/doctrine_and_domainevents.html
http://www.whitewashing.de/2012/08/22/building_an_object_model__no_setters_allowed.html
http://www.whitewashing.de/2012/08/18/oop_business_applications__command_query_responsibility_seggregation.html

php – 将业务逻辑放在实体中的更多相关文章

  1. php – 你会如何为这个应用程序建模?

    如果数据模型变得更复杂怎么办?所有这些都是你拥有域模型的原因,为什么它实际上是MVC的基本构建块:最终,用户拥有的心智模型将与数据模型不同步,原因有多种,我不会进入这里.关键是,它几乎总是发生.我确定这是必要的吗?我是否肯定这不仅仅是矫枉过正,一堆仪式咒语对于这么小的项目毫无意义?

  2. php – 将业务逻辑放在实体中

    我已经阅读了福勒关于“贫血领域模型”的文章(链接:http://www.martinfowler.com/bliki/AnemicDomainModel.html),我同意他的观点.我试图创建一个实体是简单POPO的应用程序,但是这样,我有一个胖服务层,而将一些逻辑放到实体中将是最简单的解决方案.所以我会有这样的架构:哪里:实体:将是简单的POPO,只是一袋二传手和吸气剂模型:将是用业务逻辑装饰的

  3. POCO,DTO,DLL和贫血域模型

    )),并由MartinFowler在07年由贫血领域模型出现。通过缺乏理解,我想我已经创造出了这些贫血域模型之一。所以通常我会这样创建一个dto:并将其传递给bll层,如下所示:这又反过来执行一些逻辑,并将其传递给dal层,如下所示:从我的理解,要使我的dto进入POCO,我需要使业务逻辑和行为(方法)成为对象的一部分。实现这一点的POCO方式是以这种方式设计你的界面:这是更可发现的,因为开发者知道在哪里寻找飞机飞行。

  4. java – 域模型映射器应该是静态的吗?

    在我参与的许多项目中,我们经常会有很多类将内容从一个域模型映射到另一个域模型.例如,从WSDL生成的模型到项目特定的模型.例如这也可以是一个非静态方法,服务层可以有一个映射器对象字段,而不是调用静态方法:我发现两种方法都使用了很多,但是:>以任何方式提高效率的解决方案之一?>任何解决方案都被认为是最佳实践吗?

  5. c# – 域驱动设计的存储库模式是否成为反模式?

    请考虑以下示例图像,我想说的话.解决方法我同意IRepository界面通常是浪费时间.如果我将基本的CRUD操作放在我的IRepository接口中,那么如何处理数据呢像审计数据呢?

  6. c# – MVVM中Model和ViewModel的澄清和命名约定

    我将城市模型作为POCO,然后对于城市列表,我将创建一个具有可观察的CityModel集合的Cityviewmodel.但那又怎样?我应该将Cityviewmodel作为CountryModel的一部分吗?也许是这样,有人可以澄清一下.这是我更加困惑的地方,因为我创建了一个具有属性Name,Location和List类型属性的CountryModel,但是我如何在MVVM中正确表示这一点?

  7. c# – 工厂模式这应该存在于DDD中?

    我已经讨论了一段时间了,但仍然没有得出结论.虽然我看到大多数示例都在应用程序层中有工厂代码,但我倾向于认为它应该在域层中.原因:我有时会在我的工厂进行初始验证,我希望所有对象的创建都能通过.我希望此代码可用于我的对象的所有实例化.有时,操作需要感觉不自然的参数信息传递给构造函数.还有一些不那么重要的原因.有没有理由说这是一种不好的做法?

  8. c# – 域模型中的域服务与实体方法

    我知道域和应用程序服务之间的区别.但是无法真正看到域实体和域服务中方法之间的区别:/我有一个游戏,有状态,玩家等等.它还有Addplayer,MoveLeft,Jump等方法.这些方法去哪儿了?鲍勃叔叔在他的文章here中写道:“一个实体可以是一个带有方法的对象,或者它可以是一组数据结构和功能.”我甚至不想提及像Move或Jump这样的方法也必须在AppServices中,在KOGameAPI中–因为UI需要这些方法.这是我的班级:那么,结束我的问题:域服务有哪些方法,域实体有哪些方法?

随机推荐

  1. PHP个人网站架设连环讲(一)

    先下一个OmnihttpdProffesinalV2.06,装上就有PHP4beta3可以用了。PHP4给我们带来一个简单的方法,就是使用SESSION(会话)级变量。但是如果不是PHP4又该怎么办?我们可以假设某人在15分钟以内对你的网页的请求都不属于一个新的人次,这样你可以做个计数的过程存在INC里,在每一个页面引用,访客第一次进入时将访问时间送到cookie里。以后每个页面被访问时都检查cookie上次访问时间值。

  2. PHP函数学习之PHP函数点评

    PHP函数使用说明,应用举例,精简点评,希望对您学习php有所帮助

  3. ecshop2.7.3 在php5.4下的各种错误问题处理

    将方法内的函数,分拆为2个部分。这个和gd库没有一点关系,是ecshop程序的问题。会出现这种问题,不外乎就是当前会员的session或者程序对cookie的处理存在漏洞。进过本地测试,includes\modules\integrates\ecshop.php这个整合自身会员的类中没有重写integrate.php中的check_cookie()方法导致,验证cookie时返回的username为空,丢失了登录状态,在ecshop.php中重写了此方法就可以了。把他加到ecshop.php的最后面去就可

  4. NT IIS下用ODBC连接数据库

    $connection=intodbc_connect建立数据库连接,$query_string="查询记录的条件"如:$query_string="select*fromtable"用$cur=intodbc_exec检索数据库,将记录集放入$cur变量中。再用while{$var1=odbc_result;$var2=odbc_result;...}读取odbc_exec()返回的数据集$cur。最后是odbc_close关闭数据库的连接。odbc_result()函数是取当前记录的指定字段值。

  5. PHP使用JpGraph绘制折线图操作示例【附源码下载】

    这篇文章主要介绍了PHP使用JpGraph绘制折线图操作,结合实例形式分析了php使用JpGraph的相关操作技巧与注意事项,并附带源码供读者下载参考,需要的朋友可以参考下

  6. zen_cart实现支付前生成订单的方法

    这篇文章主要介绍了zen_cart实现支付前生成订单的方法,结合实例形式详细分析了zen_cart支付前生成订单的具体步骤与相关实现技巧,需要的朋友可以参考下

  7. Thinkphp5框架实现获取数据库数据到视图的方法

    这篇文章主要介绍了Thinkphp5框架实现获取数据库数据到视图的方法,涉及thinkPHP5数据库配置、读取、模型操作及视图调用相关操作技巧,需要的朋友可以参考下

  8. PHP+jquery+CSS制作头像登录窗(仿QQ登陆)

    本篇文章介绍了PHP结合jQ和CSS制作头像登录窗(仿QQ登陆),实现了类似QQ的登陆界面,很有参考价值,有需要的朋友可以了解一下。

  9. 基于win2003虚拟机中apache服务器的访问

    下面小编就为大家带来一篇基于win2003虚拟机中apache服务器的访问。小编觉得挺不错的,现在就分享给大家,也给大家做个参考。一起跟随小编过来看看吧

  10. Yii2中组件的注册与创建方法

    这篇文章主要介绍了Yii2之组件的注册与创建的实现方法,非常不错,具有参考借鉴价值,需要的朋友可以参考下

返回
顶部