建筑难题

Question

当你在一个人的项目上工作时，最糟糕的事情是你通常从同事那里得不到投入。因为缺乏这些，你往往会犯明显的错误。

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

我开始了一个小型的家庭酿造项目，它应该变成某种门户。最让我困扰的是我编造的持久层。对于初学者来说，它应该与表示层完全分离，或者映射器也在某个位置。这是因为我有多个必须使用的数据存储。

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

我面临的主要问题如下：

用于同一概念的多个类--有一个用户的DAL表示和一个用户的BL表示以及一个用户的视图表示。我可以用工具来处理转换，但这真的是正确的方法吗？我的意思是，它们都很好地分开了，但是开销是相当大的。

你认为如何？我是太深地陷入了分离的关注兔子洞，还是这仍然正常？

Answer 1

这比正常情况要多。

通常没有人这样做，在呈现html或类似的时候，没有人会为ORM延迟加载问题而哭泣。

编写DTO层比同时考虑DA、BLL和UI更容易。有些人甚至更进一步，在架构规模中应用命令和查询分离，清楚地在输入/输出之间划出界限(这解决了诸如需要人工业务对象(实际上仅用于报告目的)等问题)。

另一方面-这要看情况。如果您的应用程序要简单，您可能不需要那么多抽象(例如，简单的公司组合主页)。

Answer 2

坦白说，我不觉得这有什么问题。在不同的层中为数据拥有单独的类意味着您可以更改一个而不必更改其他的。其他表示的额外成本通常是非常小的--打字速度通常不是生产力的因素。

OTOH，能够在不要求更改整个堆栈的情况下更改有关数据存储的内容，可以节省大量的时间和精力，因为通常为多个目的使用相同的构造会在进行更改时产生不可预见的副作用。

IOW，当必须通过多个层传播更改时，它通常会被适当的工具等辅助。另一方面，当您的数据层中的微小更改在您的UI中产生意外的副作用时，这总是很糟糕，并且减缓任何更改，因为您所做的任何事情都可能破坏整个系统中的任何东西。

Answer 3

这就是拥有多个正电子设备的危险。这就引出了“你是否全部需要它们”的问题？巩固他们中的任何一个是有意义的，你能吗？

我建议您阅读一下数据体系结构--我自己也是个新手，但是我从一个非常有经验的人那里得到了一些很好的输入。有一种观点认为，与物理数据库的实际组合方式相比，数据架构师更担心数据是如何定义的:我的建议是首先捕获和记录逻辑数据模型(modeling)和物理数据模型。对数据有一个真正清晰的理解将非常有帮助。

具体而言(即DA所担心的比特)是数据的定义--这是什么数据(不依赖于列和表的名称)？它是如何使用的，它意味着什么，它是在哪里创建的？同样重要的是，我们讨论的不是在您的系统中物理创建它的位置，而是在业务流程(Es)中创建的位置。是的，您需要担心系统--但这是以后的事；业务流程应该驱动系统。这些都是逻辑数据模型的东西。

一旦你有了定义，你就可以开始把它拼凑在一起了--来自不同存储库的数据是如何关联的？(这里可能更深入到物理模型中)。

一旦所有这些都清楚了，你在应用程序中如何适应它的答案就会开始变得明显起来，并且让它被记录下来会有帮助。在这种情况下，拥有好的文档实际上是必不可少的。