公司架构让我们在三个地方定义相同的枚举？
我们的公司架构被认为是松散耦合的，并且提供了很好的关注点分离。但是，我想知道我们是否“做得正确”。
例如，假设我们的业务/客户端层中有一个 Car 对象。这辆车上有一个“CarEnum”。当我们准备好将 Car 保存到数据库时，我们会将 Car 映射到 CarDTO，CarDTO 也有一个 CarEnum，其选项与业务层 Enum 中的选项完全相同。当我们的 DTO 到达服务器代码（在另一个解决方案中）时，DTO 会映射到另一个模型，其中还有另一个 CarEnum，其定义与业务和 DTO Enum 完全相同。
这感觉不对。
我没想到“好的架构”会涉及在三个地方定义相同的枚举。我认为代码应该是DRY。这是一个好的架构，还是只是将奇怪的货物崇拜编程强加给整个公司？什么是更好的替代架构？
Our company architecture is touted as being loosely coupled and and providing great separation of concerns. But, I'm wondering if we're "doing it right".
For example, let's say we have a Car object in our business / client layer. This Car has a "CarEnum" on it. When we are ready to save the Car to our database, we will map the Car to a CarDTO, which also has a CarEnum with the exact same options that are in the business layer Enum. When our DTO gets to the server code (in another solution), the DTO is mapped to yet another model with yet another CarEnum with the exact same definition as the business and DTO Enum.
This feels wrong.
I didn't expect "good architecture" to involve defining the same Enum in three places. I thought code was supposed to be DRY. Is this good architecture or is this just forcing weird cargo cult programming on the entire company? What is a better alternative architecture?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这不是松耦合——相反，所有定义 CarEnum 的地方都是紧密耦合的。如果有人不相信这一点，只需询问他们，如果您在其中一个文件中的现有选项之间添加一个新选项并且不触及其他文件，会发生什么。这就是松散耦合代码的定义——您可以更改一个地方的细节，而不会影响其他地方。
每当您复制这样的定义时，都应该将其重构并提取到它自己的文件中。现在，所有这 3 个位置都与新文件紧密耦合，但彼此之间并不紧密耦合。
That is not loose coupling -- rather, all the places where CarEnum are defined are tightly coupled. If someone doesn't believe this, just ask them what would happen if you went and added a new option between existing ones in one of the files and didn't touch the other ones. That is the definition of loosely coupled code -- you can change details in one place without it affecting other places.
Whenever you duplicate definitions like this, it should be refactored and extracted into it's own file. Now all those 3 places are tightly coupled with the new file, but not with each other.
在 3 个地方定义“相同”枚举绝对是一种架构\设计味道。
拥有“共享类型”的程序集是很常见的。这通常包含以下内容：接口、DTO、异常和跨层有意义的枚举。重要的是它不包含这样的行为\逻辑。然后，该程序集可以由不同层共享，而不必担心耦合。
Having the "same" enum defined in 3 places is definitely an architecture\design smell.
It's common to have an assembly for "shared types". This typically contains things like: interfaces, DTOs, Exceptions and enums that make sense across layers. It importantly contains no behavior\logic as such. This assembly can then be shared by your different layers without fear of coupling.
如果层之间需要分离（即物理边界），那么这是一件好事。如果没有，那就又是建筑宇航员的事了。
If there is separation required between the layers (i.e. physical boundary) then this is a good thing. If there isn't, it's the architecture astronauts at it again.