5

我们又来到了十字路口。

我想至少在接下来的 3 年内尝试实现一种简单、经过验证的方法来构建我的应用程序。每次我要开始一个项目时，感觉就像是第一次，因为这些天来创建网站的“方式”太多了。

我有这个示例代码，我是从我购买的这个包中获得的，叫做 Design Pattern Framework 4 C#。在他们拥有的多个项目中，有一个叫做“设计模式在行动”。您可以从这里下载它https://skydrive.live.com/redir?resid=B853B0DB724C30E5!16735&authkey=!AOeHSAWa_P4vzzU

我的问题是，在您查看该解决方案之后，关于此示例，什么是好的，坏的，您会保留什么，您会删除什么，什么是不必要的等等？

我知道他们试图展示多个客户以及多个 DAO。但总的来说，这种架构会成为您将其视为“模板”的架构吗？谢谢。

4

3 回答 3

4

系统架构很像建筑架构：

  • 没有一种“正确”的方式
  • 每个人对“最好”都有自己的看法
  • “最佳”架构取决于上下文和需求
  • 风格和方法会随着时间而改变

选择架构有很多因素：

  • 上市时间——你需要多长时间才能完成？
  • 可维护性——你会是唯一维护它的人吗？开源？
  • 可扩展性——它是一个封闭的还是开放的系统？
  • 可扩展性 - 简单实用程序还是企业级？
  • 平台 - 网络或本地？台式机还是手机？

综上所述，如果您能想出一个适合您未来 3 年将要进行的每个项目的包罗万象的框架，我会感到惊讶。将 MVC、WFC、TDD、DDD 等视为可用于构建满足该情况需求的正确系统的工具。

我的意见是：只要适合特定情况，使用任何你能理解的概念（必要时可以教给其他人）。

于 2012-08-23T15:34:06.203 回答
2

我的问题是，在您查看该解决方案之后，关于此示例，什么是好的，坏的，您会保留什么，您会删除什么，什么是不必要的等等？

快速浏览后，这就是我要说的：

  • 关于您问题上的 DDD 标签，这显然不是域驱动的架构。除了一些简单的验证规则和 DDD 架构的许多基本构建块（聚合、值对象等）外，业务对象看起来很乏味。

  • 除非我遗漏了什么，否则大多数业务操作都是 CRUD 操作，它并不能真正代表现实世界的企业应用程序。

  • 有一个胖 Service 层和一个胖 ActionService 类，它基本上似乎处理了应用程序的所有用例。好消息是，它以不可知的方式处理用例（据我所知，它操作的 Request 和 Response 对象是独立于交付机制的）。肥胖是不太可取的，因为该课程包含太多责任（SRP）。

  • 在客户端使用存储库和在服务器端使用 DAO 似乎很奇怪，但为什么不呢？

  • 如果它真的是测试驱动的，为什么不包括所有单元测试而不仅仅是一个样本呢？

除此之外，这些层设计得很好，并且正如多个表示层所显示的那样，用一个前端替换另一个前端或一个持久存储替换另一个应该不难。

于 2012-08-24T12:20:15.043 回答
0
  1. 选一个。
  2. 试试看。
  3. 如果不适合您，请重构/更改。

最重要的是确保您使用可重构的模式。如果您使用 TDD 并发现可以注入依赖项、伪造品等，那么这将简化重构过程。三年对于使用任何给定的模式来说都是很长的时间。一位朋友说，如果你不看 6 个月前的代码并认为它​​很烂，那么你可能学得还不够 :)

于 2012-08-23T15:55:55.863 回答