I recently attended the DotNetwork user group 10th gathering. This was a very exciting opportunity to meet with one of the stars of the field of architecture down under (in Australia for those who don’t know the lingo). The presenter was Omar Besiso an Australian/Egyptian architect. I really enjoyed this session and had great technical discussions with this guy. So without further ado, here is my dump of the event.
The event consisted of 2 sessions:
- Building Scalable and functional software using dependency and policy injection.
Omar started talking about Architecture Myths (as he like to call them, with some disagreement from me 🙂 )
3 Tier Architecture
His argument here was that even though this was a great model, it was rarely achieved despite developers’ and designers’ best intentions and the end result was always a tightly coupled solution between the UI and Business and Data Access layers.
The argument here was the same as above with the added factor of increased complexity.
Codegen- Tight coupling business logic and data access
I definitely disagreed here, as I am one of the major Codegen evangelists, but he explained his reasoning behind this to the fact that if you are not using the right patterns (e.g. the provider pattern), you will ultimately end up with tightly coupled solution.
Architecture and design are an overhead
This is a myth usually promoted by project managers, and the answer to this is, "if everything is an overhead then it is time to start selling your assets"
- Architecture not an option
- Imagine the maintenance nightmare of tightly coupled software if you do not plan your architecture before hand to avoid this, this alone can justify the additional "overhead" of architecture.
- Time to respond top changes in business logic, imagine what it would be like if your business logic was tightly coupled with your UI, you know the projects, we’ve all been involved in them at some stage 🙂
- Re-write the entire solution, think of how many times you had to re-write an entire solution because your Solution was built like a "house of cards" (quote from Ron Jacobs), once a component is removed or changed, everything falls apart.
Then he went on to explain what software needs to be:
A great example here was given about how when you have a performance issue ion your solution and you do not have time to re-write entirely no then you throw more hardware, till you "re-factor" the code into something that can achieve your performance and scalability requirements, this is a workaround to get around un maintainable code while having time constraints. I have personally used this workaround and it has gotten me out of very difficult situations.
Good software development need to be:
Then he went on to explain the architectures of the future that they are just:
- Adaptations of the past, which is a natural process of evolution in the software world.
- Design patterns and modern frameworks are basically hyping the patterns of the past that existed as early as the late 70s.
New architectures are destroying religious debates like:
- SPs vs. Dynamic SQL
- WCF vs. Web services
- Web vs. Windows
- WPF vs. Silverlight
SharePoint vs. ASP.NET
On to dependency injection….
Dependency Injection (Interface Based Programming)
- Adds more modularity on top of OOP
- Every small project is a big project
- Entire implementation is a testable unit
- Internal dependencies need to be defined
- Implementation is interchangeable
The service locator
- Locates the service implementation
- Used by the consumer
- Can be configuration ore code based
There was no standard
- Factories were used in a random fashion
Is like UDDI at the application level (my comment).
The IOC (Inversion of Control) container
- TURNS THE SERVOCE LOCATOR INTO A GLORIFIED SMART FACTORY
- Can manage object lifetime
- Can create not one object but the entire chain of objects needed for an operation
Many providers of IOC like:
- Unity (Enterprise Library)
- Structure Map
- Spring .NET
- Objects need to change behavior, which is where IOC is very handy.
- Cross cutting issues need to be Aspects (Aspect Oriented concepts)
Know your framework, this is important for development teams who
heavily rely on frameworks (everyone who is sane these days), a good thing
to do would be to use a reflector on the .NET framework and look at the namespaces that interest you.
- Globalizing solutions, i.e. institutionalize the frameworks within your company.
Train the people, extremely important when dealing with today’s complex frameworks.
For more info on this topic and a very detailed perspective check out Meligy’s blog