在一个人的项目中工作时最糟糕的事情是缺乏你通常从同事那里得到的意见。由于缺乏这一点，您往往会犯明显的错误。
在这条路上走了一段时间后，我需要社区的帮助。
我开始了一个小小的自制项目，该项目应该会变成某种形式的门户。困扰我的主要是我设计的持久层。对于初学者来说，它应该与表示层完全分开，并且 OR 映射器也在某处。这是因为我有多个必须使用的数据存储。
因此基本想法是各个“存储库”在各自的数据库上运行，然后业务层聚合业务对象，然后在表示层中将其转换为视图对象。
我面临的主要问题如下：
同一概念的多个类 - user 的 DAL 表示和 user 的 BL 表示和一个视图的表示用户。我可以使用工具处理转换，但这真的是正确的方法。我的意思是它们都很好地分开了，但是开销是相当大的。
你怎么看？我是不是太深入关注分离兔子洞了，还是这仍然正常？
【问题讨论】：
标签： architecture separation-of-concerns
这超出了正常范围。
通常没有人这样做，并且在渲染 html 或诸如此类时会抱怨 ORM 延迟加载问题。
编写 DTO 层比同时考虑 DA、BLL 和 UI 更容易。有些更进一步，在架构规模上应用命令和查询分离，清楚地在输入/输出之间划清界限（这解决了需要实际仅用于报告目的的人工业务对象等问题）。
另一方面 - 这取决于。如果您的应用要简单，您可能不需要这么多抽象（例如简单的公司投资组合主页）。
【讨论】：
坦率地说，我认为这没有问题。在不同的层中为数据提供不同的类意味着您可以更改一个而无需更改其他的。其他表示的额外成本通常非常小 - 打字速度通常不是生产力的因素。
OTOH，能够更改有关数据存储的某些内容而不必更改整个堆栈可以为您节省 吨 时间和精力，因为经常将相同的构造用于多种目的会导致无法预料的结果进行更改时的副作用。
IOW，虽然必须通过多个层传播更改可能很糟糕，但通常可以通过适当的工具等来辅助。另一方面，当数据层中的微不足道的更改具有在您的 UI 中出现无法预料的副作用，总是很糟糕，并且会减慢任何更改，因为您所做的任何事情都可能破坏整个系统中的任何内容。
【讨论】：
这就是拥有多个存储库的危险。这引发了“你是否都需要它们”的紧迫问题？合并其中任何一个是否有意义，您可以吗？
我建议您阅读一些有关数据架构的内容 - 我自己是一个完全的新手，但我从一位非常有经验的人那里得到了一些很好的意见。一种观点是，数据架构师更关心数据的定义方式，而不是物理数据库的实际组合方式：我的建议是从捕获和记录（建模）逻辑数据模型开始，和物理的。对数据有一个非常清晰的了解将大有帮助。
具体的（即 DA 担心的位）是数据的定义 - 这部分数据是什么（不要依赖列名和表名）？它是如何使用的，它是什么意思，它是在哪里创建的？同样重要的是，我们不是在谈论它在您的系统中物理创建的位置，而是在业务流程中创建的位置。是的，您需要担心系统-但那是以后的事了；业务流程应该驱动系统。这都是逻辑数据模型的东西。
一旦有了定义，您就可以开始将它们拼凑起来——来自不同存储库的数据是如何关联的？ （这里可能更多地涉及物理模型）。
一旦所有这些都清楚了，关于如何将其融入应用程序的答案应该开始变得显而易见，并且将其记录在案会有所帮助。这就是拥有良好文档确实必不可少的实例之一。
【讨论】：