I have read several articles about onion architecture and they all point to the fact that the problem of layer architecture is that changes in the database would impact the services layer, but, why would that be so if the connection between both layers is made through an interface?. Any explanation will be welcome.
Asked
Active
Viewed 67 times
1 Answers
0
The Onion architecture is explicitly embracing the facade pattern.
Whereas the Layered / Tiered architecture does not mandate the usage of this pattern. It "only" imposes a constraint on the communication direction. It should not be bidirectional rather than the upper can access the lower layer.
Please also note that there is a variant of layered architecture where an given layer can access not just the directly below layer but any layer below it.
Peter Csala
- 17,736
- 16
- 35
- 75
-
Sorry, but your answer is not responding the question. I have to insist: Why I have to modify my services after changing my database (of course we suppose the new database is implementing the same interface than the previous one). Somebody did a negative vote to my question and IMO, it could be fine, but just if the voter provide an answer that proves the question was nonsense. Seems as stackoverflow is no longer what it was. People should start to feel fear to ask a question here. – lm2a May 16 '23 at 12:24
-
@lm2a What I have tried to explain in my post is that in an n-tier application you **could** use interfaces (or any other abstractions) to define contracts between the layers but it is not required. In case of the onion architecture it is embracing the facade pattern to **do** define the contract between the components. – Peter Csala May 16 '23 at 13:05
-
@lm2a If you have an abstraction between the layers/tiers/components then that allows you to change the implementation of the consumed module without the need to touch the consumer code. That's what exactly you do when you are mocking the lower tier. Does it make more sense now? – Peter Csala May 16 '23 at 13:08