建筑难题 [英] Architectural conundrum

问题描述

在进行单人项目时，最糟糕的事情是缺乏通常从同事那里获得的意见.由于缺乏这一点，您往往会犯明显的错误.

The worst thing when working on a one man project is the lack of input that you usually get from your coworkers. And because of the lack of that you tend to make obvious mistakes.

沿着这条路走了一段时间后，我需要社区的帮助.

After going down that road for some time I would need some help from the community.

我开始了一个小的自制项目，它应该会变成某种门户.困扰我的主要事情是我炮制的持久层.对于初学者来说，它应该与表示层完全分离，并且 OR 映射器也在某处.这是因为我有多个必须使用的数据存储.

I started a little home-brew project that should turn into a portal of some sorts. And the main thing that is bothering me is the persistence layer that i have concocted. It should be completely separated from the presentation layer for starters and a OR mapper is also somewhere. This is because I have multiple data stores that have to be used.

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

So the base idea was that the individual "repositories" operate each on their individual database and that the business layer then aggregates the business objects which are then transformed in the presentation layer into view objects.

我面临的主要问题如下:

The main problem I face is the following:

同一概念的多个类 - 有 user 的 DAL 表示和 user 的 BL 表示以及用户.我可以使用工具处理转换，但这真的是正确的方法吗?我的意思是它们都很好地分开，但开销很大.

Multiple classes for the same concept - There is a DAL representation of a user and BL representation of user and a view representation of a user. I can handle the transformation with a tool but is this really the right way. I mean they are all nicely separated, but the overhead is quite something.

你怎么看?是我对分离关注的兔子洞太深了还是这仍然正常?

What do you think? Am I going too deep into the separation of concern rabbit hole or is this still normal?

推荐答案

这超出了正常范围.
通常没有人会这样做，并且在渲染 html 或诸如此类时会抱怨 ORM 延迟加载问题.

This is more than normal.
Usually no one does this and cries about ORM lazy loading issues when rendering html or whatnot.

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

It's easier to write DTO layer than to think about DA, BLL and UI simultaneously. Some go even further and apply command & query separation in architectural scale clearly drawing line between input/output (that solves problems like need for artificial business object that actually is used for reporting purposes only).

另一方面 - 这取决于.如果您的应用会很简单，您可能不需要太多抽象(例如简单的公司投资组合主页).

On the other hand - it depends. If your app is going to be simple, you might not need so much abstraction (e.g. simple company portfolio home page).

这篇关于建筑难题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！