Web Service Software Factory: Beyond the Service Interface (part 1)

The Web Service Software Factory still is one of my favorite .Net tools, so I was very pleased that is fully available as Visual Studio Tools extension, which makes the installation of it a piece of cake!

The overall architecture of services built using the Service Factory worked very well for the services I build in the last view years. I am a great fan of this figure illustrating the layers of a service:


However the Web Service Software Factory helps you creating the service interface layer, you are on your own when it comes to the other two.

In this post I will explain my way of implementing the business and resource access layers.

Business Entities

Every project should start with implementing the domain model, because it represents the vocabulary and key concepts of the problem domain. The entities are POCO classes (Plain Old CLR Objects) and should only contain properties and associations with other entities. Entities should not implement business logic other than validation. So methods on entity classes are only used for advanced ways of getting and setting the properties and associations that cannot be done through the getters and setters alone.

It’s wise to include one or more class diagrams in your entity project to have a complete overview on what you are doing.

Business Logic

The Web Service Software Factory documentation talks about the Transaction Script or Business Action pattern to implement the entry point into the Business Layer when called from higher layers. Just doing this can result in huge monolithic classes with a lot of methods. To prevent this I use Business Action interfaces in my projects with just one method:

public interface IBusinessAction
	Response Execute(Request request);

Where Request and Response can be business entities, for example:

public interface ICustomerSalesOrdersSelectAction
	ICollection<SalesOrder> Execute(Customer customer);

Sometimes a request can’t be just one business entity, or string, or integer (an ID for example). In that case a specific request can be added to the business logic. Not to the business entities, because it is just a query-like request, for example:

public class CustomerSalesOrdersPagedRequest
	public Customer Customer { get; set; }
	public int Skip { get; set; }
	public int Take { get; set; }

The Business Action interfaces can be implemented directly by classes from the Data Access Logic (repositories) or Service Agents. The usage of interfaces gives us the option of resolving their implementation through a dependency container (as Unity) from within the Service Interface Layer! This way the Business Logic doesn’t need to have references to Resource Access Layer components, unlike what is written in the Web Service Software Factory documentation.

To be continued…


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: