【问题标题】:ASP.net MVC : IS this pattern reasonable or conceptually incorrect?ASP.net MVC:这种模式是合理的还是概念上不正确?
【发布时间】:2009-05-16 18:57:01
【问题描述】:

我的控制器将请求转交给相应的服务。然后服务调用各种存储库。存储库将 Linq to Sql 实体纯粹用于 DataAccess,然后映射并作为域对象返回。然后服务决定 Controller 将呈现什么并将 DO 替换为 Presentation 对象,这些对象返回给 Controller 以在 View 中显示。

所以我有服务-存储库-域对象-表示对象

我之所以这么问,是因为我似乎有很多对象,有些对象除了传递数据之外什么都不做。这是一个合理的场景还是我没有遵循正确的 MVC 模式?

【问题讨论】:

    标签: asp.net-mvc model-view-controller design-patterns


    【解决方案1】:

    是的,你的想法是对的。它可以是很多类和接口(甚至不包括单元测试和模拟/测试类),但如果你有一个大小合适的应用程序,那么无论如何你都是诽谤。但一开始,工作量很大,初期收获不大。

    我看到一些项目跳过了一些基本服务的服务实现,这些服务只是传递到存储库,服务没有增加任何价值。他们从控制器直接进入存储库,似乎并没有损失太多。

    还有其他方法可以通过在可能的情况下使用工具来减轻某些课程的负担。例如,AutoMapper 之类的项目可以帮助您简化域对象以查看模型映射。

    【讨论】:

    • 当我变得懒惰时,我想直接去存储库进行简单的操作,认为这是浪费时间。所以我猜不只是我?
    • 当然不只是你。我开始通过服务进行严格访问,但已经转向跳过瘦服务。我想如果他们没有添加太多东西,以后可以很容易地添加它们。如果需要额外的功能,我只是尝试快速围绕存储库创建服务。
    【解决方案2】:

    如果您的应用程序足够大,那么您的模式就有意义。否则,我闻到过度工程的味道......

    问问自己:如果这一层不存在,你会发现它是真是假。

    【讨论】:

    • 但我可能想在以后扩展,然后呢?是不是最好做好准备?
    【解决方案3】:

    我有一个非常相似的场景。最初我的项目有 UI、控制器、服务层和存储库。我的单元测试涵盖了服务层和存储库(过滤器),在某些情况下,单元测试也在做同样的事情(因为服务层有时是对存储库的传递)。

    由于进行了大型重构,我删除了服务层,这给了我很大的灵活性,控制器直接处理存储库并应用过滤器来获得我想要的东西。

    我遇到的一个问题是您无法序列化 Linq2Sql 对象,因此有时必须将这些对象转换为表示对象。

    【讨论】:

      猜你喜欢
      • 2015-08-21
      • 1970-01-01
      • 2012-04-14
      • 1970-01-01
      • 1970-01-01
      • 2017-04-11
      • 2011-03-07
      • 1970-01-01
      • 2022-01-19
      相关资源
      最近更新 更多