组织解决方案需要遵循哪些标准？

Question

我一直在开发一个内部管理应用程序，该应用程序具有帮助自动化人们工作的各个方面的工具。该解决方案目前包含大约 40 种不同的表单，用于不同的目的。

我想知道是否应该遵循任何行业标准来将解决方案分解为单个项目/解决方案。我是否应该将所有这些表格作为根本解决方案的一部分？

我想在添加更多功能之前进行重组，因为这感觉像是一种不好的做法，并且在涉及大型解决方案时我想改进我的整体设计方法。

一些粗略的谷歌搜索出现了一些关于 Web 服务（数据访问层、服务器、客户端等）的不同层分离的结果，但该应用程序目前仅用于桌面。

我没有足够高的声誉来发布图片，但当前组织在解决方案的根级别拥有所有表单，并且只是按字母顺序列出的表单（如预期的那样），例如：frmAddEquipment 、frmAssignSoftware、frmBackupReports、frmContacts等

Answer 1

即使在桌面应用程序中，您也应该有图层。将您的应用程序分离为数据访问、业务逻辑和表示层将对您的应用程序施加结构和架构限制，从而提高可重用性、可支持性和可测试性。

这当然假设您使用了基于层的架构模式。如果您没有，并且您的所有数据和业务逻辑都被捕获在您的表单中，并在各种表单上复制，那么您可能拥有我们所说的“ball of mud”架构，并且必须做出一些严肃的决定。你可以

1. 将您的应用程序重构为目标架构 或
2. 接受您已经构建了一次性应用程序，并继续您当前的路径。

如果您决定重构为目标架构，它的模式通常意味着您的问题的解决方案。它将具有自然地允许您的应用程序适合各种项目的组件。如果你选择坚持下去，再多的重命名或项目拆分都无济于事，你只会让一个复杂的解决方案变得更加复杂，随意的规则，所以你还是保持简单吧。