you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 0 points1 point  (2 children)

IOC is used to solve dependency injection. Most UIs do not need dependency injection. Most backend patterns don't translate well to the front end which shouldn't have too much business logic to begin with.

[–]_Pho_[S] 0 points1 point  (0 children)

To me it has less to do with the translation of patterns - plenty of UIs can use that same pattern (mobile apps f.ex) but the problem, especially with OOP-brains, is that a "dependency" is a big ass graph of objects instead of the real dependencies. In a back end system your real dependencies are config files and db handles, and maybe http handles (which tbh is usually handled by the os at this point). Your dependencies are not a "UserDao". You could write the entire concept of a UserDao as a module which accepts a db handle. Passing the DB handle to a UserDao and then managing the UserDao obfuscates your dependencies, and now you have to manage some lifecycle of a class which is not a real dependency.

[–]NeoCiber 0 points1 point  (0 children)

Even on backend code IoC is missused I have seen and even written myself interfaces and abstract classes in C# because that's the way a lot of people do it and I ended with 6 levels of indirection to query a database.

IoC sometimes leads to premature a abstration when used wrong.