建筑难题

Question

在一个人项目上工作最糟糕的事情是你通常从同事那里得到的输入很少。而且由于缺乏这一点，你往往会犯明显的错误。

在这条路走了一段时间后，我需要社区的帮助。

我开始了一个小家庭酿造项目，应该变成某种类型的门户网站。而困扰我的主要事情是我编造的持久层。它应该与启动器的表示层完全分离，并且OR映射器也在某处。这是因为我有多个必须使用的数据存储。

因此，基本思想是各个“存储库”在各自的数据库上运行，然后业务层聚合业务对象，然后在表示层中将其转换为视图对象。

我面临的主要问题如下：

相同概念的多个类 - 用户的DAL表示和用户的BL表示以及a的视图表示用户。我可以使用工具处理转换，但这确实是正确的方法。我的意思是他们都很好地分开了，但开销很大。

你怎么看？我是否太深入关注兔洞的分离还是这仍然是正常的？

Answer 1

这比平常更多 通常没有人这样做，并在渲染html或诸如此类的东西时对ORM延迟加载问题感到愤怒。

编写DTO层比同时考虑DA，BLL和UI更容易。有些甚至更进一步，并应用命令＆amp;建筑规模中的查询分离清楚地描绘了输入/输出之间的界限（这解决了实际仅用于报告目的的人工业务对象需要的问题）。

---

另一方面 - 这取决于。如果你的应用程序很简单，你可能不需要那么多的抽象（例如简单的公司组合主页）。

Answer 2

坦率地说，我没有看到这个问题。在单独的图层中为数据设置单独的类意味着您可以更改其中一个而无需更改其他图层。其他表示的额外成本通常非常小 - 打字速度通常不是生产力的因素。

OTOH，能够在没有义务更改整个堆栈的情况下更改数据存储的某些内容可以为您节省大量的时间和精力，因为经常使用相同的构造用于多种目的会导致无法预料改变时的副作用。

IOW，虽然必须通过多层传播更改可以吸吮，但通常可以通过适当的工具等来辅助它。另一方面，当您的数据层发生微不足道的变化时您的用户界面无法预见的副作用，始终糟透了，并且减慢任何更改，因为您执行的操作可能会破坏整个系统中的任何内容。

Answer 3

存在多个存储库的危险。这就提出了“你是否需要它们”的即时问题？合并其中任何一个是否有意义，你能吗？

我建议你做一些关于数据架构的阅读 - 我自己是一个完整的新手，但我从一个非常有经验的人那里得到了一些很好的意见。一种观点认为数据架构师更关心数据的定义方式而不是物理数据库的实际组合方式：我的建议是从捕获和记录（建模）逻辑数据模型开始，和物理的。清楚地了解数据将有很大帮助。

具体问题（即DA担心的位置）是数据的定义 - 这些数据是什么（不依赖列和表名）？它是如何使用的，它是什么意思，它在哪里创建？同样重要的是，我们不是在讨论它在系统中物理创建的位置 - 而是在业务流程中创建它的位置。是的，你需要担心系统 - 但这是为了以后;业务流程应该驱动系统。 Thsi是所有逻辑数据模型的东西。

获得定义后，您可以开始拼凑它们 - 来自不同存储库的数据如何相关？ （可能更多地进入物理模型）。

一旦清楚了解你在应用程序中如何适应它的答案应该开始变得明显，并且记录它将有所帮助。 thsi曾经是那些拥有良好文档实际上必不可少的实例。