Listen Now

The three-tiered application is a ubiquitous pattern for a solid design. The three tiers are:

• User interface
• Business logic
• Data access

The dependency is straight down. The user interface depends upon the business logic. It feeds events from the user back into the business logic. It does not directly access the data. The business logic layer invokes the data access layer in order to read and write raw data from the database and other sources, like web services.

While this pattern successfully sheids the user interface from the raw data, it does not effectively sheild the user from the implementation.

Alan Cooper's book About Face 2.0: Essentials of User Interaction Design describes the difference between the implementation model and the conceptual model. The conceptual model is how the user thinks about the problem, and the implementation model is how the program solves it. The differences between the two cause confusion on the user's part, and bugs on the program's. The user interface's direct dependency upon the business logic means that the implementation of the business logic becomes visible to the user.

Here's my solution
On several occasions, I have had the need to insert a fourth layer into an application. Between the user interface and the business logic, I have added an interaction layer. In this case, the dependency is not straight down: the interaction layer does not completely hide the business logic from the user interface. Instead, the interaction layer is the entry point into the business layer. It fills in the gaps when the conceptual model differs from the implementation model, but it steps out of the way when the two coincide.

• User interface
• Interaction
• Business logic
• Data access

It is difficult to inject this layer after the fact, so I have resolved to put it in place on every application, whether it seems to need it or not. The application might really be what-you-see-is-what-you-get. But just in case you need to see something slightly different, the hook is in place.

Listen Now

Yesterday I attended a presentation at the Dallas .NET User's Group. Norm Headlam presented the Microsoft Patterns and Practices Web Service Software Factory (or Service Factory for short). You can download this tool from http://msdn2.microsoft.com/practices. Follow the "Web Service Software Factory" link.

Norm demonstrated how the Service Factory generates a solution with a set of well-organized projects. It generates a service layer, a data contract, a business layer, and a data access layer. Each of these assemblies has one and only one role. The service layer defines the web service. The data contract defines the data types that are exchanged between the client and the server. The business layer contains all of your business rules. And the data access layer interfaces with the database.

No longer will you return a dataset from a web service. These layers are separated according to best practices.

Norm showed how the Service Factory offers ongoing guideance. It doesn't just generate this skeleton and leave you to fill it in. Instead, you right-click on your projects to add data objects, data containers, and service endpoints. As you work, the Service Layer keeps a log of your changes. And it gives you links to your most likely next step.

Web services are no longer generated from your code. Instead, your code is generated from your contracts. You can import a database schema as a data object in the data access layer. Or you can import an XML schema to generate an object in the data contract. This is not like NHibernate, where the data layer is generated at runtime from business objects. This actually does it the right way, where the stored procedures that your DBA authors are honored, and all code is generated at design time.

The only problem I have with Microsoft's Web Service Software Factory is the name. This is not a Software Factory.

According to the book (Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools), a software factory is a set of tools that generate several products within a software product line. All products in a product line serve the same vertical domain. They are described using domain specific languages.

"Web services" is not a product line. It is a horizontal slice of software technology, not a vertical problem domain. And these tools, useful as they are, are not a domain specific language. I look forward to using Service Factory on a real project in the near future, but I will also continue to create software factories in the real sense of the term.

Listen Now

Colorful language is not terribly helpful in a bug report. The best quality assurance professionals document what they were doing, the expected behavior, and the actual behavior. The outstanding quality assurance engineers probe deeper to find patterns. Let me tell you about one such individual: Chris Sachnik.