1

我正在构建一个 MVC4 应用程序，我首先使用了 EF5 模型，并保持它非常简单。这不会涉及一个庞大的应用程序，一次只会有 4 或 5 个人在上面，并且所有用户都将在能够访问应用程序的任何部分之前进行身份验证，这非常简单 - 调度员看到订单- 调度员完成订单排序的应用程序。

基本上我的问题是，如果我的应用程序的大小和范围如此之小，我是否需要担心存储库和 ViewModel。任何强类型化到域实体的视图都在使用该实体中的所有属性。我在我的控制器中使用 TryOrUpdateModel 并且已经阅读了一些内容说这可能会导致很多问题，但没有太多关于这些问题究竟是什么的信息。我不想为一个非常简单的应用程序使用极其复杂的模式。

希望我已经提供了足够的详细信息，如果有人想查看我的代码只是问，我真的在这里遇到了障碍，并且真的可以使用社区的一些建议。非常感谢！

4

3 回答 3

1

根据我的经验，对软件解决方案的需求往往会随着时间的推移而演变，远远超出最初的需求集。

现在通过遵循架构最佳实践，您将能够更好地适应解决方案在其整个生命周期内的更改。

Respository 模式和 ViewModel 都很强大，实现起来并不困难或耗时。我建议将它们用于小型项目。

于 2013-01-28T18:32:00.427 回答
1

是的，您仍然想使用存储库和查看模型。这两种工具都允许您将代码放在一个地方而不是到处，这样可以节省您的时间。很有可能，它也会为您节省复制粘贴错误。

此外，拥有这些工具将使您将来更容易扩展系统，而不必倾注所有可读性差的代码。

分离您的关注点将导致整体代码更少，系统更高效，控制器/代码部分更小。视图模型和存储库实施起来并不严重。这不像您要实现控制器工厂或依赖注入。

于 2013-01-28T18:32:54.627 回答
1

视图模型：是的

将 EF 实体直接传递给视图时，我只看到坏点：

  • 您需要手动添加白名单或黑名单，以防止过度发布和批量分配
  • 很容易不小心从视图中延迟加载额外数据，导致选择 N+1 问题
  • 在我个人看来，模型应该与视图上显示的信息非常相似，并且在大多数情况下（基本的 CRUD 内容除外），视图包含来自多个实体的信息

存储库：否

实体框架 DbContext 已经是存储库和工作单元模式的实现。如果您希望一切都是可测试的，只需针对单独的数据库进行测试。如果你想让事情松散耦合，有一些方法可以用 EF 做到这一点，而无需使用存储库。老实说，我真的不明白自定义存储库的受欢迎程度。

于 2013-01-28T18:39:21.927 回答