标签: separation-of-concerns

我一直在试图围绕DDD以及它与MVC的关系,但我在实体识别方面遇到了麻烦.

特别是,我试图在我的演示文稿,域和数据模型之间保持严格的分离.我的问题在于如何保持跨越这些边界的实体识别.为了澄清,我使用单独的类来表示不同上下文中的相同实体 - 例如,我有一个'ShipmentRequest'域类,几个'ShipmentRequestView'表示类(取决于特定视图所需的属性),以及'shipment_request'数据库表(我的数据模型).

我觉得使用'ID'属性(如ShipmentRequestId)会违反我想要实现的分离,因为这个ID属性是一个数据库问题,而不是域关注; 我不想在图层之间传递相同的对象,因为这意味着将不需要的数据传递到我的表示层.

如何保留这种分离,并跟踪这些层之间的身份？

我想成为一个更好的开发者......

我正在做的事情:

1. .Net MVC Framework 1.0
2. 实体框架3.5

我一直在做一些阅读,我想我想做的是:

1. 为域中的每个聚合创建存储库.例如,订单存储库将管理订单的OrderItems.
2. 创建服务层以处理业务逻辑.每个存储库都有一个具有类似方法的相应服务对象.
3. 在存储库和服务之间创建过去的DTO
4. 可能会创建ViewModel,这是View要使用的类.

我有一个基础存储库接口,我的聚合存储库接口将实现...

public interface IRepository<T>
    {
        IEnumerable<T> ListAll();
        T GetById(int id);
        bool Add(T entity);
        bool Remove(T entity);
    }

我的订单存储库界面定义如下......随着我对这个学习练习的更多了解,可能还会有其他方法.

public interface IOrderRepository : IRepository<Order>
{
}

我的服务类基本上定义为与存储库相同,除了每个服务实现包括业务逻辑.这些服务将在构造函数中使用一个存储库接口(在本练习中我还没有为IoC做好准备,但我相信这就是我最终要走的路).

1. 存储库实现将使用Entity Framework从数据库推送和拉取.检索数据时; 这些方法只返回DTO而不是EF生成的对象
2. 服务(因为我正在调用它们)将控制存储库并执行业务逻辑.您将在控制器中看到这些服务,即_orderService.GetById(1).
3. 这是我开始翻转的地方并且可以使用一些反馈......我是否应该让我的服务类填充ViewModel类...我应该没有ViewModel类....也许这是从一种类型到另一种类型的过多映射？

我希望得到一些关于我关注问题的方向的反馈意见.

谢谢

即当MVC不是一个选项时,MVP仍然是下一个最佳选择吗？

我想我会在这里问这个,因为我确信还有像我这样的其他人没有奢侈品参与绿地项目,并希望重构webforms UI以更好地分离演示文稿和业务对象. .

我正在开发一个遗留应用程序,其任务是添加相对较少的附加要求,增强功能和错误修复程序.

我在这里解决的应用程序部分可能被描述为一组CRUD操作的UI,这些操作是持久存储到关系数据库的业务对象.

现有UI使用MultiView控件在关联业务对象(一对一关联或一对多/父子对象)的编辑之间进行导航.是的,这是对的 - 所有这一切都在一页上.不幸的是,UserControls的使用非常少,因此标记和代码隐藏的时间长达数百行.

在每个View上,FormView通过各种ObjectDataSource管理业务对象上的CRUD.在每个FormView的ItemTemplate中,各种服务器控制数据绑定到ObjectDataSource上的字段或方法.

我想引入更多的关注点分离,并从页面代码中获取一些代码.

到目前为止,我的研究建议我可以考虑:

1. 使用Model View Presenter的风格 ; 更具体地说 - 使用Web客户端软件工厂中的ObjectContainerDataSource,可以更轻松地在当前UI和一组新的Presenter类之间进行桥接.

2. 使用MVC框架(不是选项)从头开始构建.

3. 别管; 如果我需要在不同的UI场景中重用我的演示文稿,MVP模式是否合理？

如果我满意(3)我仍然想知道如何开始重构以更好地分离演示.

你会怎么做？感恩的任何其他想法......

这里有一些感兴趣的人的背景:

该领域是在药物研究领域,但这是相当无关紧要的,您可以将其视为非常典型的业务线 - 一系列设置的用户配置,这些设置构成了应用程序另一部分的操作条件.

业务对象层已经以非常一致的方式构建.虽然我可能不喜欢它,但我无法证明改变它是正确的.每个对象都是它自己的存储库/数据访问对象,因为存在"按ID获取"和"按标准获取列表"的静态方法.在可能的情况下,常见操作在抽象基类中实现.每个业务对象都将数据访问工作委托给数据访问层,该数据访问层利用ADO.NET 2.0 Provider Factory机制来保持与具体Provider相对抽象.在这方面,它与使用Microsoft企业库中的数据访问应用程序块的任何应用程序共享很多共同点.

在NUnit中编写了相当详尽的集成测试,它们从头开始设置测试数据库,因此它们需要很长时间才能运行,但至少他们会验证这些内容是否正常工作(无论如何在过去的某些时候;-).几乎没有真正的单元测试(还).

在几个示例项目中,我已经看到ViewModels用于将数据对象转换为字符串,以便在View中使用.

ViewModel通常会有一个构造函数,它接收一个参数 - 一个数据对象.然后构造函数将填充ViewModel的各种属性(主要是字符串和整数).

这可以防止在View中出现任何复杂的逻辑.

乍一看,这对我来说似乎是个好主意,因为它更完全地强化了View与复杂逻辑的分离.

例如,假设我的视图试图渲染数据对象的属性"大小",大小是1到3之间的数字,表示"小/中/大".

我不会在视图中使用if/switch语句,而是在ViewModel中只有一个'SizeString'或类似的东西,而if/switch语句将放在ViewModel构造函数中.

有人不同意这种方法吗？

使用其他方法(例如助手)会更好吗？如果是这样,为什么？

嘿伙计们,这里只是一个小问题..(希望如此!)

我一直在为PHP MVC框架尝试一堆不同的目录结构.在这样做时,我想到了将应用程序的不同部分彼此分开的几个原因.

例如,假设这是我目前的结构:

- index.php
- private/
    - application/
        - ... (MVC stuff. Irrelevant I think...)
    - config/
        - config.php
    - framework/
        - bootstrap.php
        - includes/
        - library/
            - ... (Framework classes)
    - libraries/
        - Zend/
        - PEAR/
 - public/
     - css/
     - images/

我拥有它的方式,我可以简单地通过覆盖/ private/framework /目录来更新框架,这不会影响/ private/config /中的用户框架配置,也不会影响/ private/libraries /中的第三方库.

该的index.php文件用于几乎完全加载/private/framework/bootstrap.php文件,这将意味着在更新/私营/框架/目录也将有更新更新主引导文件(救了我/ index.php文件,它将保持原样,因为它根本没有多少).

此外,应用程序也与框架的所有内容分开,因此用户可以在需要时切换/更改/更新其应用程序,而无需担心其他目录.

我是否在正确的轨道上关于将目录彼此分离以使它们更容易更新？

我在一些框架中看到他们在他们的框架目录中都有他们的/ private/libraries /和/ private/application /目录......但是在我看来这很难更新到更新版本的框架如果需要的话.或者我是否以错误的方式思考它？

如果您有兴趣,可以在 …

据我了解,UnitOfWork类旨在表示域中业务事务的概念.它并不直接表示数据库事务,这只是一个可能的实现的细节.

问:那么为什么关于工作单元模式的大量文档会引用"提交"和"回滚"方法？

这些概念对域或域专家毫无意义.业务事务可以"完成",因此UnitOfWork应该提供"完整"方法.同样,它不应该被建模为"清除"而不是"回滚"方法吗？

更新:

答:以下两个答案都是正确的.它们是UoW的两种变体:对象注册和呼叫者注册.在对象注册中,Rollback用于撤消对所有内存中对象的更改.在调用者注册中,Rollback用于清除所有记录的更改,以便后续调用Commit将不执行任何操作.

我有一个CC-BY图像,我用它作为背景,由CSS引入.这个图像纯粹是为了它的外观,绝对不是内容.我需要在某个地方放置此图像的归属,显然最好将此归因链接到提供图像的善良人物.但是,我真的不想把链接文本放到我的HTML中,因为它打破了实际内容和表示的分离(我会说,归因链接实际上是演示文稿的一部分,因为如果您查看了没有背景图像的页面,你真的不想看到它).

有什么方法可以让我在这里分享演示文稿和内容吗？

我目前的代码看起来像

<div class='backgrounded'>
  <div class='content'><h1>Some stuff here</h1></div>
  <div class='attribution'>
    Image from <a href='http://example.com/image'>Lovely CC-BY person</a>
  </div>
</div>

而CSS:

div.backgrounded {
    background: url(/images/an_image.jpg);
}
div.attribution {
    color: #ffffff; 
    float: right;
}

这具有内容中的归属,我宁愿不拥有它.

我考虑过的其他事情包括:

• 将归因放在图像本身中.这解决了代码分离问题,但我的图像是一个很好的宽图像,位于左侧,因此有足够的背景用于宽浏览器窗口.图像的右下角几乎总是不在视野范围内.我不知道如何将此归因作为链接.

• 制作包含归因文字的图片并将其放在当前归属的位置,再次在后台,但最重要的是我想我可以使用JavaScript将其作为链接.这似乎是很多摆弄.

有没有办法在我的图像只在CSS中引用？或者失败了,保持事物分离的最佳方法是什么,以便例如可以在不编辑HTML的情况下替换图像？

应该是客户端模板,如下所示(使用下划线的模板引擎):

<p class="foo"><%= bar %></p>

被放置在单独的HTML文件或单独的JavaScript文件中？我知道它可以双向工作.

例如,JavaScript文件可能只包含一个字符串变量列表,如下所示:

var cute = '<p class="the"><%= unicorn %></p>';
var fb   = '<p class="new-design"><%= sucks %></p>';

但我也看到了以下内容:

<script type="text/template" id="omg-template">
  <span id="swag-name"><%= name %></span>
</script>

仅从分离关注的角度来看,模板存储属于哪里？

我有这个问题一直困扰着我一段时间.乍一看,它似乎是一个相当基本的问题,但似乎没有一个明确的答案.我提出这个问题的基础是一个通过SQLAlchemy使用PostgreSQL的Python项目,但使用的特定语言和工具并不重要.

基本问题是在使用ORM时放置逻辑？更具体地说,我的映射类的方法应该采用什么逻辑？

似乎有一些明确的案例,例如,属性的基本验证,例如最小长度或某些电子邮件地址是否属于ORM层(甚至是数据库本身).

一个简单的具体示例是有序的,因此我们假设我们正在存储用户对象,用户有一个电子邮件地址(这是他们唯一的ID),一个密码和一个激活ID.创建帐户时,会分配激活ID并将其邮寄给用户,然后使用该ID设置密码.

我们来看几个场景:

• 用户创建一个帐户;
• 用户激活帐户(即设置密码).

因此,当用户创建帐户时,我们需要运行一些基本验证:

• 电子邮件地址正确=> ORM;
• 电子邮件地址unique => ORM或数据库(唯一约束);
• 设置随机激活id => ORM

当用户激活她的帐户时,我遇到了问题.我想验证提供的密码(例如足够长？足够的数字？),但模型应使用某种散列或加密算法存储密码.似乎有两种选择:

1:检查模型之外的激活ID和密码有效性,散列密码然后将User.password设置为散列,并将User.activation id设置为null(以指示活动帐户).

2:创建一个User.activate(activation_id,password)方法,该方法验证每个并相应地设置User.password和User.activation_id属性.

3:混合选项,执行选项1,但在设置密码时设置某种挂钩或事件激活_id = null(如果我们假设可以设置激活ID或密码,则此挂钩满足基本一致性属性该模型).

我在互联网上搜索过,有些消息来源谈论这个问题(包括一些SO问题),但没有人真正回答这个问题.

在过去几个月中,我们一直在寻找以下问题的解决方案:前端开发人员无法在没有后端开发人员帮助的情况下轻松修改网站的外观.

我们团队的文化主要基于完整的框架,如Symfony 2和Ruby on Rails.我们使用模板引擎,但模板大多是由后端开发人员根据设计师的标记编写的.

我们要考虑的步骤是将整体架构分离为后端rest API和NodeJS服务器作为"UI服务器".NodeJS服务器将处理客户端请求,使用后端API并返回呈现的模板.通过明确指定API和服务的JSON,前端和后端开发人员可以并行工作,减少问题.更多信息:http://www.nczonline.net/blog/2013/10/07/node-js-and-the-new-web-front-end/

问题是,我们坚信这种分离对于建筑POV是一件好事,但我们担心这些缺点.我们怀疑它会让事情变得更难.我们团队中没有一个人从未使用过这种架构,因此任何提示或体验都非常有价值.

这值得么？什么时候？为什么？