Best practices for application development
1 / 41

Best Practices For Application Development - PowerPoint PPT Presentation

  • Uploaded on

Best Practices For Application Development. Steven Wilssens & Jelle Druyts Compuware .NET Consultants Goals. Write better code Document your code Apply design patterns in your code Feel confident about your code Be proud of your code.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Best Practices For Application Development' - bo-mejia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Best practices for application development

Best Practices ForApplication Development

Steven Wilssens & Jelle Druyts

Compuware .NET Consultants


  • Write better code

  • Document your code

  • Apply design patterns in your code

  • Feel confident about your code

  • Be proud of your code


  • Developing Code

  • Documenting Code

  • Designing Code

  • Testing Code

  • Building Code

Exception handling

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


Developing Code


  • 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)

Data access

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


Developing Code


  • 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)


Developing Code


  • 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


Developing Code


  • 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

Enterprise library 2 01

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

Key changes from 1 x
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

Enterprise library 2 0 blocks




& Design



Developing Code

Enterprise Library 2.0 Blocks










Optional ProviderDependency

Block Dependency

Best practices for application development

Documenting Code


  • 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

Best practices for application development

Documenting Code


  • 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){ ... }

Documentation tools

Documenting Code

Documentation Tools

  • CR_Documentor

  • NDoc (being updated for .NET 2.0)

Best practices for application development

Designing Code

Command Pattern and Enterprise Library 2.0


Allow unit testing of major part of application

Tests must be deterministic

Tests must be automated

Tests must be efficient (execute quickly)

Testing Code

Dependency principles
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

Unit testing net
Unit Testing .NET


Visual Studio Test

Testing Code

General principles
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

Test driven development
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

Code coverage basics
Code Coverage Basics

Records which parts of an application's code is being exercised by a test suite

Testing Code

Code coverage b est practices
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

Code coverage p itfalls
Code Coverage Pitfalls

Best quantifiable measure

Doesn’t say a lot about quality of tests

Beware of developer shortcuts

Testing Code

Daily build definition
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

Introducing daily builds
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

Daily build benefits
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

Key points
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

Best practices for application development

Enterprise Library 2.0

Code Documentation

XML Comments Quick Reference



Command Pattern

Thank you
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