Best Practices For Application Development

1. Best Practices ForApplication Development Steven Wilssens & Jelle Druyts Compuware .NET Consultants http://steven.wilssens.net http://jelle.druyts.net

2. Goals • Write better code • Document your code • Apply design patterns in your code • Feel confident about your code • Be proud of your code

3. Agenda • Developing Code • Documenting Code • Designing Code • Testing Code • Building Code

4. Developing Code

5. Developing Code Exception Handling • Handle exceptions consistently throughout your application • Make exception handling code simple • Best practices: • Don't disclose security sensitive information to remote callers • Add context to exceptions by wrapping or replacing exceptions • Log and monitor all exceptions that occur

6. Developing Code Logging • Log business and operations data for runtime application monitoring • Make logging code simple • Best practices: • Provide tracing to support production debugging • Provide auditing for increased security • Change logging settings through configuration • Which messages go where (file, event log, email, ...) • How the messages are formatted (templates) • When to log (information, warning, error, critical)

7. Developing Code Data Access • Read and write to commonly used databases in a simple and efficient way • Make data access code simple • Best practices: • Perform multiple updates within one transaction • Handle different database providers transparently • Separate logical from physical databases • Change connection settings through configuration • Provider type (SQL Server, Oracle, OLE-DB, ODBC, ...) • Connection string

8. Developing Code Caching • Eliminate expensive data retrieval by keeping a local copy • Make caching code simple • Best practices: • Provide different cache invalidation mechanisms (absolute time, sliding time, file change, database change, ...) • Provide different cache stores (in-memory, database) • Use a local cache for offline operations on disconnected smart clients • Don't be afraid to use the ASP.NET cache anywhere for non-persistent storage (even in Windows Forms)

9. Developing Code Cryptography • Encrypt or hash sensitive information before persisting it; decrypt or compare when reading it back • Make cryptography code simple • Best practices: • Never store passwords directly, only hash values • Only decrypt data if absolutely necessary (use a hash where possible) • Use symmetric keys to encrypt and decrypt data across multiple machines • Use Windows DPAPI for cryptography on a single machine without using keys

10. Developing Code Security • Authenticate and authorize users using one or more security systems • Make security code simple • Best practices: • Use an authentication system to see if a user can access a system • Use an authorization system to see if a user can perform a certain task • Cache authentication or authorization data for the duration of a logon session

11. Enterprise Library 2.0

12. Developing Code Enterprise Library 2.0 • Set of reusable components from Microsoft • Consistent • Extensible • Easy to use • Integrated • Source code you compile yourself • Free • Not a Microsoft product • Tested through many unit tests • Use only the blocks you need • Visual configuration tool

13. Key Changes From 1.x • Configuration Application Block no longer exists • Configuration now built on System.Configuration • Logging Application Block • Much improved flexibility and performance • Data Access Application Block • Simpler and much more powerful • Supports SQL Server, Oracle, OLE-DB, ODBC or any other managed provider • Security Application Block • Most of it deprecated in favor of .NET’s Membership and Profile features

14. Plug-in Config Helpers & Design Instrumen-tation ObjectBuilder Developing Code Enterprise Library 2.0 Blocks Data Access Logging Caching Core Cryptography Exception Handling Security Optional ProviderDependency Block Dependency

15. Enterprise Library 2.0

16. Documenting Code

17. Documenting Code Why? • Your code is not self-documenting • Undocumented code is untestable code • Easier to plan next version • Easier to return later • Brings new team members quickly up to speed • Creates happy customers

18. Documenting Code How? • Put XML comments on your code • Document all public and protected members • Learn and use the XML tags • Write additional content • User's guide & Known issues • Installation & Configuration guide • Generate documentation • CHM, HTML, HxS, ... /// <summary> /// Write a new log entry to the default category. /// </summary> /// <param name="message">Message body to log.</param> public static void Write(object message){ ... }

19. Documenting Code Documentation Tools • CR_Documentor • NDoc (being updated for .NET 2.0)

20. Designing Code

21. Designing Code Command Pattern and Enterprise Library 2.0

22. Testing Code

23. Testability Allow unit testing of major part of application Tests must be deterministic Tests must be automated Tests must be efficient (execute quickly) Testing Code

24. Dependency Principles Communicate with interfaces or base classes Separate interface definitions from implementations Use dependency injection to late-bind objects Externalize environment dependencies Externalize non-deterministic behavior Externalize timing behavior Testing Code

25. Unit Testing .NET NUnit Visual Studio Test Testing Code

26. General Principles Test cases must be independent Reproduce bugs as test cases Test only public members Place tests in separate projects Have a test project per test target Use source control on test projects Testing Code

27. Test-Driven Development Write unit tests before or in parallel with production code Unit tests help define the system Unit tests are debugging drivers Developers write the tests ”It’s better to write and run incomplete tests than not to run complete tests” Testing Code

28. Test Driven Development

29. Code Coverage Basics Records which parts of an application's code is being exercised by a test suite Testing Code

30. Code Coverage Best Practices Use code coverage to monitor your tests' effectiveness Project managers can aggregate results as a project status indicator Team members can analyze source for specific missed lines of code Set a high, but realistic target Testing Code

31. Code Coverage Pitfalls Best quantifiable measure Doesn’t say a lot about quality of tests Beware of developer shortcuts Testing Code

32. Code Coverage

33. Building Code

34. Daily Build Definition Daily builds are the results of a fully automated process which, by using source code, compiles, validates, and packages a software solution Daily builds don’t have to run each day, as long as they run frequently Building Code

35. Introducing Daily Builds ”The build is the heartbeat. If there ain’t no heartbeat, it’s dead!” Must be fully automated Difficult to do No excuse for not doing daily builds: The more complex your system is, the more you need it Building Code

36. Daily Build Benefits State of project becomes more transparent You always have a product that can potentially ship Current test target always available Anti-surprise device Reduces overall integration effort Building Code

37. Team Build

38. Key Points Developing Code Use Enterprise Library 2.0 Documenting Code Use XML comments and NDoc to generate CHM files Designing Code Command Pattern can be used to integrate many enterprise library 2.0 features Testing Code You can take a pragmatic or a formal approach to unit testing Building Code Use build verification tests to verify soundness of a build

39. Enterprise Library 2.0 http://msdn.microsoft.com/practices http://practices.gotdotnet.com/projects/entlib Code Documentation XML Comments Quick Reference http://jelle.druyts.net/2005/01/16/XMLCommentsQuickReference.aspx NDoc http://ndoc.sourceforge.net/ CR_Documentor http://www.paraesthesia.com/blog/comments.php?id=701_0_1_0_C Command Pattern http://steven.wilssens.net/

40. Thank You! Thanks for your attention We'll be happy to answer all your questions Right after the session Compuware Booth Community Booth: Ask-The-Experts VISUG Booth