标签: separation-of-concerns

互联网上使用ViewModels并使用Automapper的每篇文章都提供了"Controller - > View"方向映射的指导.您将域模型与所有选择列表一起放入一个专门的ViewModel并将其传递给视图.这很清楚也很好.
视图有一个表单,最终我们处于POST操作中.这里所有的模型绑定器与[显然]另一个视图模型一起来到现场,它显然与原始的ViewModel 相关,至少在命名约定方面是为了绑定和验证.

如何将其映射到您的域模型？

让它成为插入动作,我们可以使用相同的Automapper.但如果是更新动作怎么办？我们必须从Repository中检索我们的Domain Entity,根据ViewModel中的值更新它的属性并保存到Repository.

附录1(2010年2月9日):有时,分配模型的属性是不够的.应根据View Model的值对域模型采取一些措施.即,应该在域模型上调用一些方法.可能应该有一种位于Controller和Domain之间的应用服务层,以便处理View Models ...

如何组织此代码以及将其放置在何处以实现以下目标？

• 保持控制器薄
• 荣誉SoC实践
• 遵循领域驱动设计原则
• 干嘛
• 未完待续 ...

单一责任原则与关注点分离有什么区别？

我是 React 新手，看到充满大量函数和变量初始化以及 UI 的组件，我觉得眼睛很痛。有可能将它们分开吗？

而不是默认设置，如下所示。如何将业务逻辑分离到另一个文件中？

function MyComponent() {
    const [data, setData] = useState('');
    const someFunc = () => {
        //do something.
    };
    ... some 100-liner initializations

   return ( 
       ...
   )
}

我在过去读过一些关于模型的MVC建议,说明你不应该为域和视图重用相同的模型对象; 但我一直没能找到任何人愿意讨论为什么这是不好的.

我认为创建两个独立的模型 - 一个用于域,一个用于视图 - 然后在它们之间进行映射会产生大量重复,加上繁琐的映射代码(其中一些可能会被像AutoMapper这样的东西减轻)很可能容易出错.

是什么让这两个问题的单独模型值得重复和映射代码的麻烦？

我最近阅读了文章CQRSàlaGreg Young,我仍然试图了解CQRS.

我不确定输入验证应该在哪里发生,以及它是否可能发生在两个不同的位置(从而违反了"不重复自己"规则,可能还包括"关注点分离").

鉴于以下应用程序架构:

#      +--------------------+           ||
#      |    event store     |           ||
#      +--------------------+           ||
#           ^          |                ||
#           |  events  |                ||
#           |          v                  
#      +--------------------+         events         +--------------------+
#      |      domain/       | ---------------------> |   (denormalized)   |
#      |  business objects  |                        |  query repository  |
#      +--------------------+           ||           +--------------------+
#         ^   ^   ^   ^   ^             ||                      |
#         |   |   |   |   |             ||                      |
#      +--------------------+           ||                      |
#      |    command bus     | …

我关心的是我存储常量:

module Group::Constants
  extend ActiveSupport::Concern

  MEMBERSHIP_STATUSES = %w(accepted invited requested
    rejected_by_group rejected_group)
end

我希望使用这些常量的另一个问题是:

module User::Groupable
  extend ActiveSupport::Concern
  include Group::Constants

  MEMBERSHIP_STATUSES.each do |status_name|
    define_method "#{status_name}_groups" do
      groups.where(:user_memberships => {:status => status_name})
    end
  end
end

不幸的是,这会导致路由错误:

uninitialized constant User::Groupable::MEMBERSHIP_STATUSES

看起来第一个问题是在第二个问题中没有正确加载.如果是这样的话,我该怎么办呢？

I suppose most of the developers have an idea of multi-layer architecture. We have DAL (Data access layer), we have BLL (business logic layer) and somewhere near the end of the road we have our UI. If you have a project which somehow follows these principles, do you keep (or at least try) to keep/put the things where they conceptually belong? I'm especially interested in big company applications where you work together with many other people. Clearly you can do …

Clojure如何实现关注点分离？由于代码是数据,函数可以作为参数传递并用作返回...

并且,因为有这样的原则"更好的1000个函数可以在1个数据结构上工作,而不是100个函数在100个数据结构上"(或类似的东西).

我的意思是,将所有内容打包成地图,给它一个关键字作为关键字,就是这样吗？功能,标量,集合,一切......

通过Aspects(面向方面​​编程)和注释,在Java中实现了Separation of Concerns的概念.这是我对这个概念的看法,可能有些限制,所以不要把它视为理所当然.

什么是正确的方式(惯用的方式)在Clojure,以避免其他程序员的WTFs _

我参考ServiceStack文档注册使用POCO:

由于它促进了干净,可重复使用的代码,ServiceStack始终鼓励使用代码优先的POCO来处理所有事情.

即可以使用相同的POCO:
在请求和响应中DTO(在客户端和服务器上)
在JSON,JSV和CSV文本序列化器中
作为OrmLite,db4o和NHibernate中的数据模型
作为存储在Redis中的实体
作为存储在缓存和会话中的blob
在MQ的服务中删除并执行"

我喜欢servicestack以及使用它编写Web服务是多么容易.我试图了解如何最好地设置我的项目,而不是遇到任何问题.

具体来说,我正在与返回响应对象的架构理念作斗争,该对象也是一个数据模型(如SS所建议的).关注分离的想法在我内心过于根深蒂固.如果你对所有事情都使用相同的POCO,那么将不会遇到问题.例如,返回例如视图对象不是"更安全"吗？

以下是来自Ben Nadel的演示单页长寿AJAX应用程序的JavaScript模板示例:[来源]

<script id="contact-list-item-template" type="application/template">

    <li class="contact clear-fix">

            <div class="summary">
                    <a class="name">${name}</a>
            </div>

            <div class="actions">
                    <a href="javascript:void( 0 )" class="more">more</a> &nbsp;|&nbsp;
                    <a href="#/contacts/edit/${id}" class="edit">edit</a> &nbsp;|&nbsp;
                    <a href="#/contacts/delete/${id}" class="delete">delete</a>
            </div>

            <dl class="details clear-fix">
                    <dt>
                            name:
                    </dt>
                    <dd>
                            ${name}
                    </dd>
                    <dt>
                            phone:
                    </dt>
                    <dd>
                            ${phone}
                    </dd>
                    <dt>
                            email:
                    </dt>
                    <dd>
                            ${email}
                    </dd>
            </dl>

    </li>

我想问一下使用像这样的JavaScript模板引擎的目的是什么？它是为了节省带宽吗？这只是一个关注点分离的问题吗？它有助于对抗浏览器内存泄漏问题吗？

我应该何时使用模板引擎,何时更容易使用原始HTML AJAX响应？

相关讨论:

JQuery模板引擎