CODEWITHSUNDEEP
.netarchitecture
TaylorOtwell
TaylorOtwell

Reputation: 7337

Company architecture has us defining same Enum in three places?

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?

Upvotes: 0

Views: 235

Answers (3)

Tuna-Fish
Tuna-Fish

Reputation: 586

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.

Upvotes: 2

Tim Lloyd
Tim Lloyd

Reputation: 38434

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.

Upvotes: 1

Deleted
Deleted

Reputation: 4998

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.

Upvotes: 1

Related Questions