waf Wiki & Documentation Rss Feed

Updated Wiki: Modular Architecture

jbe2277 — Fri, 10 May 2013 07:37:02 GMT

Modular Architecture

1. Introduction

Applying only the Layered Architecture for structuring a large software system into maintainable parts might not be sufficient. The Modular Architecture can solve this issue. It extends the layering by introducing another dimension to separate the software system.

Separation dimensions:

Layers separate the software artifacts into technical groups (e.g. Presentation layer contains UI related code).
Modules separate the software artifacts into distinct parts which are often specific domain aspects (e.g. an email client might separate the email management implementation and the address book implementation into separate modules).

Figure 1: Shows the two separation dimensions of layers and modules.

2. Motivation

Applying the Modular Architecture gives us the following advantages:

Provides a simple and clean software structure.
Prevents that unrelated classes depend on each other.
Changing the implementation of a module doesn’t affect other modules.
Reduces the efforts to maintain and extend the software system. This comes of fewer dependencies in the software system.
Helps to scale the software development to more development teams. A Modular Architecture requires good interfaces between the modules. These interfaces can be used to separate the responsibilities of the development teams.
Developers can concentrate on their own modules and don’t need to understand the implementation of the other modules. They just work with the “documented” interfaces of the other modules.
Simplifies unit testing because dependent modules can be replaced by mock implementations.

Note: These advantages are not for free! They are seen only if the development teams follow the Software Architecture rules. And that requires a severe discipline of all involved developers.

3. Participants

The three types participating in a Modular Architecture are: Module; Interface; Application Framework.

Figure 2: Shows the participants of a Modular Architecture.

3.1. Module

A module contains all software artifacts for a distinct part of the software system. This distinct part represents often a specific domain/business aspect.

Characteristics

A module contains all the types that are necessary to implement the distinct part of the software system.
A module is responsible for all technical aspects. This might include the user interface for the module’s domain or the persistency. Therefore, a module consists of various layers.
A module must not have a direct dependency to another module.
Communication between modules must be decoupled by an Interface.
A module can be replaced by another module without the need to recompile the software system.
A module consists of one or more .NET Assemblies.

Common Issues

A module has an assembly reference to another module. As a result, these modules aren’t decoupled of each other.
Avoid creating too much modules in a software system. The overall complexity will rise because the communication between the modules must be decoupled.
A module does not focus on the specific part for which it is responsible for. This results in a negative impact on the understandability and manageability of the code.

3.2. Interface

The interface exposes the public functionality of a module. Different modules can communicate via this interface with each other.

Characteristics

An interface contains the types that are necessary to expose the public functionality of one module.
Other modules might use this public functionality. Thus, they have a direct dependency to the interface.
The types can be:
- Interfaces
- Data Transfer Objects (DTO). These are simple immutable objects without any logic.
- EventArgs. These classes are similar to DTOs.
The number of types in the interface assembly should be low. This ensures low coupling between the modules.
An interface consists of one or more .NET Assemblies. In most scenarios only one .NET Assembly is used.

Common Issues

If the interface contains a lot of types then this can be a sign that the module boundaries are not chosen well. Bloating interfaces tighten the coupling between the modules and this lowers the advantages of the Modular Architecture (see 2. Motivation).
Every module that exposes public functionality must provide it’s on interface assemblies. An interface is implemented by only one module but it can be used by any module.
Avoid exposing the module’s domain objects via the interface. Instead, create a DTO object which contains the required data.

Quality

Changing the interfaces has a huge impact on the whole software system. Therefore, the quality of the interfaces is very important. Here are some recommendations to improve the quality of the interface assemblies:

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the interface members.
Write a document about the usage of the module’s public functionality. Consider to add important design decisions regarding the interface to this document.

3.3. Application Framework

The application framework is the foundation for the software system. It contains all the types that should be shared between multiple modules.

Characteristics

The application framework might provide reusable types of various layers. Examples:
- Presentation layer: Custom controls, global ResourceDictionaries
- Domain layer: Custom base class for domain objects
The WPF Application Framework (WAF) can also be seen as application framework. It provides types that can be used by all modules (e.g. ViewModel).

Common Issues

Avoid using the application framework to overcome the effort to decouple the module communication.
Do not implement types that are used by only one module. These types should reside within the responsible module.

Quality

Changing the application framework has a major impact on the whole software system. All modules might have a dependency to this framework. For that reason, the quality is very important. Here are some recommendations to improve the quality of the application framework:

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the public types and members.
Write a document about the usage and architecture of the application framework.

4. Alternative: Extensions

Sometimes it is not appropriate to separate a part of the system into two modules because they would have to work tightly together. Consequently, this would create a bloating interface for the communication.

In that case the usage of an extension might be the better choice. An extension is part of the module and thus, it is able to access the internal implementation.

Figure 3: Shows the dependency between the core implementation and the extension.

Example

The BookLibrary sample application comes with a reporting extension. This extension allows the user to create reports about the books in the library. The extension needs full access to the Book and Person entities (domain objects).

Characteristics

The extension can easily be replaced with another implementation (e.g. a mock implementation to simplify the unit testing of the module).
The module might be implemented in a way that the availability of the extension is optional.
An extension is part of one module. It cannot be reused by other modules.

Updated Wiki: Downloads

jbe2277 — Sun, 21 Apr 2013 13:33:03 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.5	Apr 21 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.5

Experimental

Platform	Version	Date	Download
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Sat, 23 Mar 2013 10:51:39 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.4	Mar 23 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.4

Experimental

Platform	Version	Date	Download
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Sat, 23 Feb 2013 16:09:35 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.3	Feb 23 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.3

Experimental

Platform	Version	Date	Download
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Sat, 26 Jan 2013 14:17:26 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.2	Jan 26 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.2

Experimental

Platform	Version	Date	Download
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Sat, 26 Jan 2013 14:17:12 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.2	Jan 26 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.2

Experimental

Platform	Version	Date	Download
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Sat, 26 Jan 2013 14:15:42 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.2	Jan 26 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.2

Experimental

.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Thu, 10 Jan 2013 21:02:35 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.1	Jan 10 2013 (NEW)	WPF Application Framework (WAF) 3.0.0.1
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Downloads

jbe2277 — Thu, 10 Jan 2013 21:01:09 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	3.0.0.1	Jan 10 2013	WPF Application Framework (WAF) 3.0.0.1
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

New Comment on "Modular Architecture"

jbe2277 — Sat, 05 Jan 2013 13:28:11 GMT

Please use Discussions or Issue Tracker for Feedback.

Updated Wiki: Home

jbe2277 — Sat, 05 Jan 2013 13:25:45 GMT

Project Description

The WPF Application Framework (WAF) is a lightweight Framework that helps you to create well structured WPF Applications. It supports you in applying a Layered Architecture and the Model-View-ViewModel (aka MVVM, M-V-VM, PresentationModel) pattern.

Downloads

Downloads Overview: Lists the WPF Application Framework (WAF) downloads for various platforms (e.g. .NET4.5, .NET4, .NET3.5, WPF, Windows Forms, Silverlight3).

Features

Architecture
- Layered Architecture [1-4]
- Modular Architecture [1, 2]
- Extensions [3]
- Model-View-ViewModel Pattern [1-4]
- DataModel-View-ViewModel Pattern [1, 3]
- UI extension services [2]
User Interface
- View Composition [1-4]
- UI Workflow [2-4]
- Modal Dialogs [2-4]
- Filter data [2, 3]
- Sort data [3]
- Custom Control [2]
- Tabbed MDI [4]
- Animated page transition [4]
- Reporting via FlowDocument [3]
Domain
- Validation with DataAnnotations and IDataErrorInfo [1-3]
Persistence
- Entity Framework [3]
- SQL Server Compact Edition [3]
Miscellaneous
- DelegateCommand [1-4]
- INotifyPropertyChanged [1-4]
- Weak Events [1-4]
- Recent file list [1, 4]
- MessageService [1-4]
- FileDialogService [1, 4]
- Print [3, 4]
- Print Preview [4]
- Export Document as XPS [4]
- Localization [4]
- Unit Testing [1-4]

Footnotes

[1] The WPF Application Framework (WAF) directly supports this feature.

[2] The Information Manager sample application shows how to implement this feature.

[3] The Book Library sample application shows how to implement this feature.

[4] The Writer sample application shows how to implement this feature.

Updated Wiki: Modular Architecture

jbe2277 — Sat, 05 Jan 2013 13:19:14 GMT

Modular Architecture

1. Introduction

It might not be good enough to apply only the Layered Architecture for structuring a large software system into maintainable parts. The Modular Architecture can solve this issue. It extends the layering by introducing another separation dimension.

Separation dimensions:

Layers separate the software artifacts into technical groups (e.g. Presentation layer contains UI related code).
Modules separate the software artifacts into distinct parts which are often specific domain aspects (e.g. an email client might separate the email management implementation and the address book implementation into separate modules).

Figure 1: Shows the two separation dimensions of layers and modules.

2. Motivation

Applying the Modular Architecture gives us the following advantages:

Provides a simple and clean software structure.
Prevents that unrelated classes depend on each other.
Changing the implementation of a module doesn’t affect other modules.
Reduces the efforts to maintain and extend the software system. This comes of fewer dependencies in the software system.
Helps to scale the software development to more development teams. A Modular Architecture requires good interfaces between the modules. These interfaces can be used to separate the responsibilities of the development teams.
Developers can concentrate on their own modules and don’t need to understand the implementation of the other modules. They just work with the “documented” interfaces of the other modules.
Simplifies unit testing because dependent modules can be replaced by mock implementations.

Note: These advantages are not for free! They are seen only if the development teams follow the Software Architecture rules. And that requires a severe discipline of all involved developers.

3. Participants

The three types participating in a Modular Architecture are: Module; Interface; Application Framework.

Figure 2: Shows the participants of a Modular Architecture.

3.1. Module

A module contains all software artifacts for a distinct part of the software system. This distinct part represents often a specific domain/business aspect.

Characteristics

A module contains all the types that are necessary to implement the distinct part of the software system.
A module is responsible for all technical aspects. This might include the user interface for the module’s domain or the persistency. Therefore, a module consists of various layers.
A module must not have a direct dependency to another module.
Communication between modules must be decoupled by an Interface.
A module can be replaced by another module without the need to recompile the software system.
A module consists of one or more .NET Assemblies.

Common Issues

A module has an assembly reference to another module. As a result, these modules aren’t decoupled of each other.
Avoid creating too much modules in a software system. The overall complexity will rise because the communication between the modules must be decoupled.
A module does not focus on the specific part for which it is responsible for. This results in a negative impact on the understandability and manageability of the code.

3.2. Interface

The interface exposes the public functionality of a module. Different modules can communicate via this interface with each other.

Characteristics

An interface contains the types that are necessary to expose the public functionality of one module.
Other modules might use this public functionality. Thus, they have a direct dependency to the interface.
The types can be:
- Interfaces
- Data Transfer Objects (DTO). These are simple immutable objects without any logic.
- EventArgs. These classes are similar to DTOs.
The number of types in the interface assembly should be low. This ensures low coupling between the modules.
An interface consists of one or more .NET Assemblies. In most scenarios only one .NET Assembly is used.

Common Issues

If the interface contains a lot of types then this can be a sign that the module boundaries are not chosen well. Bloating interfaces tighten the coupling between the modules and this lowers the advantages of the Modular Architecture (see 2. Motivation).
Every module that exposes public functionality must provide it’s on interface assemblies. An interface is implemented by only one module but it can be used by any module.
Avoid exposing the module’s domain objects via the interface. Instead, create a DTO object which contains the required data.

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the interface members.
Write a document about the usage of the module’s public functionality. Consider to add important design decisions regarding the interface to this document.

3.3. Application Framework

The application framework is the foundation for the software system. It contains all the types that should be shared between multiple modules.

Characteristics

The application framework might provide reusable types of various layers. Examples:
- Presentation layer: Custom controls, global ResourceDictionaries
- Domain layer: Custom base class for domain objects
The WPF Application Framework (WAF) can also be seen as application framework. It provides types that can be used by all modules (e.g. ViewModel).

Common Issues

Avoid using the application framework to overcome the effort to decouple the module communication.
Do not implement types that are used by only one module. These types should reside within the responsible module.

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the public types and members.
Write a document about the usage and architecture of the application framework.

4. Alternative: Extensions

The extension can easily be replaced with another implementation (e.g. a mock implementation to simplify the unit testing of the module).
The module might be implemented in a way that the availability of the extension is optional.
An extension is part of one module. It cannot be reused by other modules.

Updated Wiki: Modular Architecture

jbe2277 — Sat, 05 Jan 2013 13:14:11 GMT

Modular Architecture

1. Introduction

Layers separate the software artifacts into technical groups (e.g. Presentation layer contains UI related code).
Modules separate the software artifacts into distinct parts which are often specific domain aspects (e.g. an email client might separate the email management implementation and the address book implementation into separate modules).

Figure 1: Shows the two separation dimensions of layers and modules.

2. Motivation

Applying the Modular Architecture gives us the following advantages:

Provides a simple and clean software structure.
Prevents that unrelated classes depend on each other.
Changing the implementation of a module doesn’t affect other modules.
Reduces the efforts to maintain and extend the software system. This comes of fewer dependencies in the software system.
Helps to scale the software development to more development teams. A Modular Architecture requires good interfaces between the modules. These interfaces can be used to separate the responsibilities of the development teams.
Developers can concentrate on their own modules and don’t need to understand the implementation of the other modules. They just work with the “documented” interfaces of the other modules.
Simplifies unit testing because dependent modules can be replaced by mock implementations.

Note: These advantages are not for free! They are seen only if the development teams follow the Software Architecture rules. And that requires a severe discipline of all involved developers.

3. Participants

The three types participating in a Modular Architecture are: Module; Interface; Application Framework.

Figure 2: Shows the participants of a Modular Architecture

3.1. Module

A module contains all software artifacts for a distinct part of the software system. This distinct part represents often a specific domain/business aspect.

Characteristics

A module contains all the types that are necessary to implement the distinct part of the software system.
A module is responsible for all technical aspects. This might include the user interface for the module’s domain or the persistency. Therefore, a module consists of various layers.
A module must not have a direct dependency to another module.
Communication between modules must be decoupled by an Interface.
A module can be replaced by another module without the need to recompile the software system.
A module consists of one or more .NET Assemblies.

Common Issues

A module has an assembly reference to another module. As a result, these modules aren’t decoupled of each other.
Avoid creating too much modules in a software system. The overall complexity will rise because the communication between the modules must be decoupled.
A module does not focus on the specific part for which it is responsible for. This results in a negative impact on the understandability and manageability of the code.

3.2. Interface

The interface exposes the public functionality of a module. Different modules can communicate via this interface with each other.

Characteristics

An interface contains the types that are necessary to expose the public functionality of one module.
Other modules might use this public functionality. Thus, they have a direct dependency to the interface.
The types can be:
- Interfaces
- Data Transfer Objects (DTO). These are simple immutable objects without any logic.
- EventArgs. These classes are similar to DTOs.
The number of types in the interface assembly should be low. This ensures low coupling between the modules.
An interface consists of one or more .NET Assemblies. In most scenarios only one .NET Assembly is used.

Common Issues

If the interface contains a lot of types then this can be a sign that the module boundaries are not chosen well. Bloating interfaces tighten the coupling between the modules and this lowers the advantages of the Modular Architecture (see 2. Motivation).
Every module that exposes public functionality must provide it’s on interface assemblies. An interface is implemented by only one module but it can be used by any module.
Avoid exposing the module’s domain objects via the interface. Instead, create a DTO object which contains the required data.

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the interface members.
Write a document about the usage of the module’s public functionality. Consider to add important design decisions regarding the interface to this document.

3.3. Application Framework

The application framework is the foundation for the software system. It contains all the types that should be shared between multiple modules.

Characteristics

The application framework might provide reusable types of various layers. Examples:
- Presentation layer: Custom controls, global ResourceDictionaries
- Domain layer: Custom base class for domain objects
The WPF Application Framework (WAF) can also be seen as application framework. It provides types that can be used by all modules (e.g. ViewModel).

Common Issues

Avoid using the application framework to overcome the effort to decouple the module communication.
Do not implement types that are used by only one module. These types should reside within the responsible module.

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the public types and members.
Write a document about the usage and architecture of the application framework.

4. Alternative: Extensions

The extension can easily be replaced with another implementation (e.g. a mock implementation to simplify the unit testing of the module).
The module might be implemented in a way that the availability of the extension is optional.
An extension is part of one module. It cannot be reused by other modules.

Updated Wiki: Modular Architecture

jbe2277 — Sat, 05 Jan 2013 13:08:54 GMT

Modular Architecture

1. Introduction

Layers separate the software artifacts into technical groups (e.g. Presentation layer contains UI related code).
Modules separate the software artifacts into distinct parts which are often specific domain aspects (e.g. an email client might separate the email management implementation and the address book implementation into separate modules).

Figure 1: Shows the two separation dimensions of layers and modules.

2. Motivation

Applying the Modular Architecture gives us the following advantages:

Provides a simple and clean software structure.
Prevents that unrelated classes depend on each other.
Changing the implementation of a module doesn’t affect other modules.
Reduces the efforts to maintain and extend the software system. This comes of fewer dependencies in the software system.
Helps to scale the software development to more development teams. A Modular Architecture requires good interfaces between the modules. These interfaces can be used to separate the responsibilities of the development teams.
Developers can concentrate on their own modules and don’t need to understand the implementation of the other modules. They just work with the “documented” interfaces of the other modules.
Simplifies unit testing because dependent modules can be replaced by mock implementations.

Note: These advantages are not for free! They are seen only if the development teams follow the Software Architecture rules. And that requires a severe discipline of all involved developers.

3. Participants

The three types participating in a Modular Architecture are: Module; Interface; Application Framework.

Figure 2: Shows the participants of a Modular Architecture

3.1. Module

A module contains all software artifacts for a distinct part of the software system. This distinct part represents often a specific domain/business aspect.

Characteristics

A module contains all the types that are necessary to implement the distinct part of the software system.
A module is responsible for all technical aspects. This might include the user interface for the module’s domain or the persistency. Therefore, a module consists of various layers.
A module must not have a direct dependency to another module.
Communication between modules must be decoupled by an Interface.
A module can be replaced by another module without the need to recompile the software system.
A module consists of one or more .NET Assemblies.

Common Issues

A module has an assembly reference to another module. As a result, these modules aren’t decoupled of each other.
Avoid creating too much modules in a software system. The overall complexity will rise because the communication between the modules must be decoupled.
A module does not focus on the specific part for which it is responsible for. This results in a negative impact on the understandability and manageability of the code.

3.2. Interface

The interface exposes the public functionality of a module. Different modules can communicate via this interface with each other.

Characteristics

An interface contains the types that are necessary to expose the public functionality of one module.
Other modules might use this public functionality. Thus, they have a direct dependency to the interface.
The types can be:
- Interfaces
- Data Transfer Objects (DTO). These are simple immutable objects without any logic.
- EventArgs. These classes are similar to DTOs.
The number of types in the interface assembly should be low. This ensures low coupling between the modules.
An interface consists of one or more .NET Assemblies. In most scenarios only one .NET Assembly is used.

Common Issues

If the interface contains a lot of types then this can be a sign that the module boundaries are not chosen well. Bloating interfaces tighten the coupling between the modules and this lowers the advantages of the Modular Architecture (see 2. Motivation).
Every module that exposes public functionality must provide it’s on interface assemblies. An interface is implemented by only one module but it can be used by any module.
Avoid exposing the module’s domain objects via the interface. Instead, create a DTO object which contains the required data.

Quality
Changing the interfaces has a huge impact on the whole software system. Therefore, the quality of the interfaces is very important. Here are some recommendations to improve the quality of the interface assemblies:

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the interface members.
Write a document about the usage of the module’s public functionality. Consider to add important design decisions regarding the interface to this document.

3.3. Application Framework

The application framework is the foundation for the software system. It contains all the types that should be shared between multiple modules.

Characteristics

The application framework might provide reusable types of various layers. Examples:
- Presentation layer: Custom controls, global ResourceDictionaries
- Domain layer: Custom base class for domain objects
The WPF Application Framework (WAF) can also be seen as application framework. It provides types that can be used by all modules (e.g. ViewModel).

Common Issues

Avoid using the application framework to overcome the effort to decouple the module communication.
Do not implement types that are used by only one module. These types should reside within the responsible module.

Quality
Changing the application framework has a major impact on the whole software system. All modules might have a dependency to this framework. For that reason, the quality is very important. Here are some recommendations to improve the quality of the application framework:

Apply code reviews.
Activate Code Analysis with “Microsoft All Rules”.
Enable XML Comments. Use them to document the public types and members.
Write a document about the usage and architecture of the application framework.

4. Alternative: Extensions

Sometimes it is not appropriate to separate a part of the system into two modules because they would have to work tightly together. Consequently, this would create a bloating interface for the communication.

In that case the usage of an extension might be the better choice. An extension is part of the module and thus, it is able to access the internal implementation.

Figure 3: Shows the dependency between the core implementation and the extension.

Example
The BookLibrary sample application comes with a reporting extension. This extension allows the user to create reports about the books in the library. The extension needs full access to the Book and Person entities (domain objects).

Characteristics

The extension can easily be replaced with another implementation (e.g. a mock implementation to simplify the unit testing of the module).
The module might be implemented in a way that the availability of the extension is optional.
An extension is part of one module. It cannot be reused by other modules.

Updated Wiki: Documentation

jbe2277 — Sat, 05 Jan 2013 13:00:45 GMT

Documentation

Architecture

Layered Architecture

Modular Architecture

Model-View-ViewModel Pattern

DataModel-View-ViewModel Pattern

Introduction of the IoC container concept.
This page might help you to understand what MEF does in the sample applications.

Sample Applications

Waf Information Manager (PDF)
A modular application that comes with a fake email client and an address book.

Architecture	User Interface
Layered Architecture	View Composition
Modular Architecture	UI Workflow (e.g. Wizard)
Model-View-ViewModel (MVVM)	Modal Dialogs
UI extension services	Custom Control
	Filter data
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Domain	Miscellaneous
Validation (IValidatableObject)	Weak Events
	Unit Testing

Waf Book Library (PDF)
Supports the user to manage his books. Borrowed books can be tracked by this application.

Architecture	User Interface
Layered Architecture	Reporting via FlowDocument
Extensions	Print reports
Model-View-ViewModel (MVVM)	View Composition
DataModel-View-ViewModel	Modal Dialogs
	Sort and Filter data
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Domain	Persistence
Validation (DataAnnotations)	Entity Framework
	SQL Server CE
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Miscellaneous
Weak Events
Unit Testing

Waf Writer (PDF)
A simplified word processing application.

Architecture	User Interface
Layered Architecture	Tabbed MDI
Model-View-ViewModel (MVVM)	View Composition
	Animated page transition
	Recent file list
	Modal Dialogs
	Message and FileDialogService
	Print Dialog and Print Preview
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Miscellaneous
Localization with language selection
Document Management
Export FlowDocument as XPS
Weak Events
Unit Testing

Waf Localization Sample (PDF)
Demonstrates a simple way to localize a WPF application.

External Sample Applications

Waf Stopwatch

Architecture: Layered Architecture; Model-View-ViewModel (MVVM)
User Interface: View Composition; Animated page transition; Modal Dialogs
Domain: Validation (CustomValidationAttribute)
Miscellaneous: Localization; Click Once; Weak Events; Unit Testing

Waf File Hash Generator

Architecture: Layered Architecture, Model-View-ViewModel (MVVM)
User Interface: View Composition, Drag and Drop, Windows 7 Taskbar
Miscellaneous: Asynchronous Code, Localization, Click Once, Weak Events, Unit Testing

Migration

Upgrading from WPF Application Framework (WAF) 1.0

Updated Wiki: Downloads

jbe2277 — Thu, 03 Jan 2013 10:07:16 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.1	Jan 03 2013	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	2.5.0.440	Mar 09 2012	WAF for .NET 4.5 (Experimental)
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Documentation

jbe2277 — Mon, 31 Dec 2012 17:10:06 GMT

Documentation

Architecture

Layered Architecture

Model-View-ViewModel Pattern

DataModel-View-ViewModel Pattern

Introduction of the IoC container concept.
This page might help you to understand what MEF does in the sample applications.

Sample Applications

Waf Information Manager (PDF)
A modular application that comes with a fake email client and an address book.

Architecture	User Interface
Layered Architecture	View Composition
Modular Architecture	UI Workflow (e.g. Wizard)
Model-View-ViewModel (MVVM)	Modal Dialogs
UI extension services	Custom Control
	Filter data
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Domain	Miscellaneous
Validation (IValidatableObject)	Weak Events
	Unit Testing

Waf Book Library (PDF)
Supports the user to manage his books. Borrowed books can be tracked by this application.

Architecture	User Interface
Layered Architecture	Reporting via FlowDocument
Extensions	Print reports
Model-View-ViewModel (MVVM)	View Composition
DataModel-View-ViewModel	Modal Dialogs
	Sort and Filter data
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Domain	Persistence
Validation (DataAnnotations)	Entity Framework
	SQL Server CE
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Miscellaneous
Weak Events
Unit Testing

Waf Writer (PDF)
A simplified word processing application.

Architecture	User Interface
Layered Architecture	Tabbed MDI
Model-View-ViewModel (MVVM)	View Composition
	Animated page transition
	Recent file list
	Modal Dialogs
	Message and FileDialogService
	Print Dialog and Print Preview
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -	- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Miscellaneous
Localization with language selection
Document Management
Export FlowDocument as XPS
Weak Events
Unit Testing

Waf Localization Sample (PDF)
Demonstrates a simple way to localize a WPF application.

External Sample Applications

Waf Stopwatch

Architecture: Layered Architecture; Model-View-ViewModel (MVVM)
User Interface: View Composition; Animated page transition; Modal Dialogs
Domain: Validation (CustomValidationAttribute)
Miscellaneous: Localization; Click Once; Weak Events; Unit Testing

Waf File Hash Generator

Architecture: Layered Architecture, Model-View-ViewModel (MVVM)
User Interface: View Composition, Drag and Drop, Windows 7 Taskbar
Miscellaneous: Asynchronous Code, Localization, Click Once, Weak Events, Unit Testing

Migration

Upgrading from WPF Application Framework (WAF) 1.0

Updated Wiki: Downloads

jbe2277 — Sun, 09 Dec 2012 15:32:37 GMT

Downloads Overview

Stable

Platform	Version	Date	Download
.NET Framework 4.0	2.5.0.400	Dec 08 2012	WPF Application Framework (WAF) 2.5.0.400
.NET Framework 4.0	2.5.0.0	Dec 09 2012	WAF Project Template
.NET Framework 4.0	2.0.0.400	Sep 19 2011	WPF Application Framework (WAF) 2.0.0.400
.NET Framework 4.0	1.0.0.400	Aug 13 2010	WPF Application Framework (WAF) 1.0.0.400
.NET Framework 3.5 SP1	1.0.0.350	Jun 18 2010	WPF Application Framework (WAF) 1.0.0.350

Alpha

Platform	Version	Date	Download
.NET Framework 4.5	2.5.0.440	Mar 09 2012	WAF for .NET 4.5 (Experimental)
.NET Framework 3.5 SP1	1.0.0.1	Sep 19 2010	WAF Windows Forms Adapter 1.0.0.1
Silverlight 3	1.0.0.0	Jul 12 2009	WAF Concepts in Silverlight 3 (Experimental)

Updated Wiki: Home

jbe2277 — Sun, 09 Dec 2012 13:26:58 GMT

Project Description

Downloads

Downloads Overview: Lists the WPF Application Framework (WAF) downloads for various platforms (e.g. .NET4.5, .NET4, .NET3.5, WPF, Windows Forms, Silverlight3).

Features

Architecture
- Layered Architecture [1-4]
- Modular Architecture [1, 2]
- Extensions [3]
- Model-View-ViewModel Pattern [1-4]
- DataModel-View-ViewModel Pattern [1, 3]
- UI extension services [2]
User Interface
- View Composition [1-4]
- UI Workflow [2-4]
- Modal Dialogs [2-4]
- Filter data [2, 3]
- Sort data [3]
- Custom Control [2]
- Tabbed MDI [4]
- Animated page transition [4]
- Reporting via FlowDocument [3]
Domain
- Validation with DataAnnotations and IDataErrorInfo [1-3]
Persistence
- Entity Framework [3]
- SQL Server Compact Edition [3]
Miscellaneous
- DelegateCommand [1-4]
- INotifyPropertyChanged [1-4]
- Weak Events [1-4]
- Recent file list [1, 4]
- MessageService [1-4]
- FileDialogService [1, 4]
- Print [3, 4]
- Print Preview [4]
- Export Document as XPS [4]
- Localization [4]
- Unit Testing [1-4]

Footnotes

[1] The WPF Application Framework (WAF) directly supports this feature.

[2] The Information Manager sample application shows how to implement this feature.

[3] The Book Library sample application shows how to implement this feature.

[4] The Writer sample application shows how to implement this feature.

Updated Wiki: Home

jbe2277 — Sun, 09 Dec 2012 13:19:44 GMT

Project Description

Downloads

Downloads Overview: Lists the WPF Application Framework (WAF) downloads for various platforms (e.g. .NET4.5, .NET4, .NET3.5, WPF, Windows Forms, Silverlight3).

Features

Architecture
- Layered Architecture [1-4]
- Modular Architecture [1, 2]
- Extensions [3]
- Model-View-ViewModel Pattern [1-4]
- DataModel-View-ViewModel Pattern [1, 3]
- UI extension services [2]
User Interface
- View Composition [1-4]
- UI Workflow [2-4]
- Modal Dialogs [2-4]
- Filter data [2, 3]
- Sort data [3]
- Custom Control [2]
- Tabbed MDI [4]
- Animated page transition [4]
- Reporting via FlowDocument [3]
Domain
- Validation with DataAnnotations and IDataErrorInfo [1-3]
Persistence
- Entity Framework [3]
- SQL Server Compact Edition [3]
Miscellaneous
- DelegateCommand [1-4]
- INotifyPropertyChanged [1-4]
- Weak Events [1-4]
- Recent file list [1, 4]
- MessageService [1-4]
- FileDialogService [1, 4]
- Print [3, 4]
- Print Preview [4]
- Export Document as XPS [4]
- Localization [4]
- Unit Testing [1-4]

Footnotes

The WPF Application Framework (WAF) directly supports this feature.
The Information Manager sample application shows how to implement this feature.
The Book Library sample application shows how to implement this feature.
The Writer sample application shows how to implement this feature.