Comparing Inversion-Of-Control Containers

1. Comparing Inversion-Of-Control Containers Comparison of .NetIoC Containers

2. Have Your Mind Blown! http://codestock.org August 9, 2008 Knoxville, TN

3. Devlink Technical Conference http://devlink.net August 22 - 23, 2008 Murfreesboro, TN

4. Who is Chris Rauber? • A senior software developer and application architect with over 10 years experience designing, developing, building, and testing software applications • He has worked with clients ranging from Fortune 500 companies to five-persons IT shops • A polyglot programmer, with expertise in C#, Java, VB.Net, JavaScript, and Ruby. • The founder and author of Miado, an open-source data-access layer witten in C# that simplifies the use of ADO.Net. • Chris earned his Bachelor of Science in Industrial & Labor Relations from Cornell University in 1995 and his Master of Science in Computer Information Systems from Georgia State University in 1999.

5. Who is Alan Stevens? • An Independent Web Developer • PresidentEast Tennessee .NET Users Grouphttp://etnug.org • Occasional Blogger http://netcave.org • ASP Insiderhttp://aspinsiders.com • An Enthusiast NOT an expert! • A member of the elite Kung Fu Geeks…

7. As Seen On Twitter… “Inversion of Control is the scar tissue of J2EE Containers” Jeremy Miller Creator of StructureMap

8. History • Gang of Four – Design Patterns (1994) • In the discussion of the Template Method pattern: “Template methods lead to an inverted control structure that’s sometimes referred to as ‘The Hollywood Principle,’ that is, ‘Don’t call us, we’ll call you.’ ”

9. Inversion Of Control • Definition • The flow of control in a component is not controlled by the component itself, but rather by some outside entity • In other words… • Objects should not be responsible for creating and managing their own dependencies

10. Dependency Injection • A specific form of Inversion Of Control • An object’s dependencies are created by some external entity and injected into it

11. Separation Of Concerns • Break our applications into distinct modules that don’t overlap in responsibilities • Examples: • MVC • UI, Service, DAL • HTML, CSS • The goal is code that is highly cohesive with low coupling

12. Cohesion • The degree to which the responsibilities within a given class are strongly related • Highly cohesive code is: • More readable and easier to understand • Easier to manage, maintain, and test • Likely to be reused • Reduced complexity

13. Code With Low Cohesion protected void btnSubmit_click(object sender, EventArgs e) { if ( !this.IsValid(this.txtUserName.Text, this.txtPassword.Text) ) {} } private boolIsValid(string userName, string password) { boolisValid = false; using ( SqlConnectionconn = new SqlConnection(_connString) ) { using ( SqlCommandcmd = conn.CreateCommand() ) { // query on User Name and Password isValid = cmd.ExecuteScalar(); } } return isValid; }

14. Coupling • The degree to which a given concrete class is dependent on another concrete class • Reducing coupling provides: • More flexibility • Ease of swapping implementations • Ability to refactor • Components that are more testable

15. Highly Coupled Code public void ResetPassword(User user) { user.Password = PasswordGenerator.GenerateNewPassword(); MailMessage email = new MailMessage( "support@mycompany.com", user.Email, "Password Reset", String.Format("Your password has been reset to: {0}", user.Password)); SmtpClientsmtp = new SmtpClient(); smtp.Send(email); EventLog.WriteEntry( "LoginService", String.Format("Reset password for {0}", user.UserName), EventLogEntryType.Information); }

16. SOLID Principles • Single Responsibility Principle • Open Closed Principle • Liskov Substitution Principle • Interface Segregation Principle • Dependency Inversion Principle

17. The Single Responsibility Principle • A class should have one, and only one, reason to change.

18. The Open Closed Principle • You should be able to extend a classes behavior, without modifying it.

19. The Liskov Substitution Principle • Derived classes must be substitutable for their base classes.

20. The Interface Segregation Principle • Clients should not be forced to depend on interfaces that they do not use.

21. The Dependency Inversion Principle • Depend on abstractions, not on concretions.

22. *ILITIES • Agility • Testability • Reversibility • Changeability • Flexibility • Maintainability

23. Testability • Tests become very granular • Tests can focus on a class’s single responsibility, and inject mock dependencies • Testability is a good barometer of coupling • Highly cohesive, low coupled code is much easier to test

24. Agility • Dependency injection frees us to change implementations without affecting calling code • Modules become easy to refactor • Highly flexible software

25. Container? • A container is nothing more than a fancy dictionary of interfaces and their implementing types • Inversion Of Control containers act like “super factories”

26. Auto wiring • Automatically resolve inter-class dependencies • Objects are pre-populated with all their dependencies when retrieved from the container • Significantly reduces the amount of code needed to resolve dependencies

27. Lifecycle Management • Singletons are evil! • IoC containers can control instance behavior • Client code is shielded from the lifecycle decisions of its dependencies

28. Spring Framework • Rod Johnson, founder and creator • Expert One-on-One J2EE Design and Development (2002) • Our business code had become polluted with J2EE container dependencies • Writing testable J2EE apps in a traditional manner was hard • Setter injection allowed us to isolate and inject container dependencies • Dependency injection led to interfaces that were easy to “mock”

29. Unity (Microsoft) • Advantages • Microsoft • Simple, straight-forward configuration API • Method chaining when initializing • Disadvantages • Microsoft • Enterprise Library hangover • Limited feature set • New framework on the block

30. Windsor (Castle Project) • Advantages • Probably the most widely used • Full featured and well documented • Very active community • Native support for AOP • More choices for lifecycle management • Built-in support for Logging and Transactions • Plays well with other open-source tools • Disadvantages • Still only in “Release Candidate” stage

31. Ninject • Advantages • Very Fast • Full featured and well documented • Very active development • No need for XML configuration files • Highly extensible • Disadvantages • Default use of attributes • New, version 1.0

32. StructureMap • Advantages • Mature code base • Flexible configuration options • Developed by Jeremy D. Miller • Disadvantages • Flexibility leads to complexity • Documentation is lacking

33. DEMO

34. Drawbacks of IoC • Architecture is less straight-forward • Overkill for smaller or throwaway applications • Easy to abuse • Be careful to avoid “XML Hell” in configuration files

35. Resources • http://www.martinfowler.com/articles/injection.html • http://www.codeplex.com/unity/ • http://www.castleproject.org/container/ • http://www.ninject.org • http://structuremap.sourceforge.net • http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod • http://msdn2.microsoft.com/en-us/magazine/cc337885.aspx

36. Thanks For Listening! Email/IM: alanstevens@gmail.com Chris.Rauber@gmail.com Blog: http://netcave.org http://www.chrisrauber.com/blog/ Twitter: @alanstevens @chrisrauber