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