Not All Architecture is Fit for Your Apps

I had an interesting discussion over stackoverflow with L-Three in this question. I realized that it is quite an interesting situation there, so I think it need to be blogged. I'm not yet experienced enough in Dependency Injection, so my statements may be mistaken though.

In short, he is advising to use a well structured architecture. That architecture is using some several good techniques, like dependency injection and comand-query separation. Ad a moderate programmer, I can say that the structure is good, clean, easy enough to test and extendable. But I don't like it. No, not because the design is good, but I have some conditions where the architecture can't be applied.

IOC Container

Even if it is already became a common practice to use IOC container, I choose not to depend on IOC container. Why is it? Sometimes, you will found yourself in a tight-policy company, and you will having a hard time to implement any distributed components. Don't ever think about implementing a global-scale component like ORM (Entity Framework).


No, the policy is not something that must be blamed. You will understand that in enterprise-level, modify an application needs layered approvals and good deployment strategies. If you ask to tearing down an existing application that formerly use stored procedures, to use ORM; or refactoring the high coupled classes to use Dependency Injection; than you are asking for the impossibility. But maybe you can, however, modify bit by bit using strangled application development method.

Service Locator is an Anti Pattern

There is an argument about the downside of IOC.
It is a shame (little, if not big) that I mistakenly understand IOC with Service Locator pattern. Yes, I apologize for it. And when I have stated that it is service locator, looks like everybody had the same vision.
Some people said that using a static DI Container sevice locator is okay if it is just in one place, or there is no other way to inject the object. I don't yet found a real situation where there is no other way to solve the architecture without service locator. I only imagined the function to some auto mapping objects.

It is okay if the project is only developed by me, just me, or programmer who understand the danger of service locator. But if it handled by beginner developer, it can be misused and used in many other enhancements, because it is easy. I have worked in a company which hire many beginner developer, to handle enterprise sized application. It is insane, that is why I want to prevent the use of service locator in any way.

Your team's Principal is not Always Same

What do you aim during designing application? Testability? Maintainability? Reliability? Logging? Testable? It is a good thing if your team support the same principal. But if your team aim for other thing, lets said performance, then you are not in a good place to implement a heavy-architecture structure. Why? Because, usually it is designed in layered structure, with many data mapping. In high volume transaction application, the mapping process can take quite the cost. Moreover, database logic often used to speed up performance, negating the use of application BLL

Keep It Simple, Stupid

Another thing that I want to emphasize the anti-usage of command query separation (CQS) with well structured framework, is to keep my application as simple as it. So simple that even a beginner developer can enhance and debug it. That is why I can choose to keep with dependency injection, but not CQS.
Dependency Injection is a simple concept, where every OOP programmer know how to inject the object in constructor. But CQS is another thing, the abstraction level is high.

Conclusion

There is not exists the so-called "best architecture". Every software architecture will have a pros or cons depending on the situation, or what kind of characteristics (performance, testability, etc) that you want to achieve. However, there are principles that can help you to plan your software architecture to meet your needs. There exists SOLID, DRY, YAGNI, etc.