IntroductionAs you may know, designing and building flexible and reusable service layer is essential when creating robust multi-tier applications. In this article we will discuss the pros and cons of different architectural approaches to building a service layer. You will learn design patterns that help building reusable services, and we will demonstrate how they are implemented for WCF services with the open source Xomega Framework. We will also talk about the challenges of using WCF in Silverlight as well as solutions to work around those challenges.
Architectural OverviewThe first question you face before you start designing your service layer is whether your service layer will be inherently stateless or potentially stateful.
Pros and Cons of Stateless Services With purely stateless services, each request is totally independent of each other, which has its own advantages, but doesn’t quite lend itself to building flexible and reusable services as we explain next. The benefits of the stateless services are great scalability and low resource utilization, such as memory consumption and thread usage. You can load-balance your services by running a cluster of servers and each server will be able to process any request independently without consuming any memory to store the state, and then release all resources such as threads or database connections after the request has been processed. The downside, however, is that you will have to pass the entire state along with each request. This may not be a problem if your state is always relatively small, such as read/query operations or simple updates that are performed as one unit of work. In large systems and enterprise applications though that require multiple levels of validations before the data can be saved, the user state may contain numerous edits that span multiple objects. Designing a service that can take all the user edits in a single request can be a very challenging task in this case, and you will likely need to design a separate service or operation for every different scenario, which will make your services not reusable and may eventually lead to a maintenance nightmare. Read more: Codeproject
QR:
Architectural OverviewThe first question you face before you start designing your service layer is whether your service layer will be inherently stateless or potentially stateful.
Pros and Cons of Stateless Services With purely stateless services, each request is totally independent of each other, which has its own advantages, but doesn’t quite lend itself to building flexible and reusable services as we explain next. The benefits of the stateless services are great scalability and low resource utilization, such as memory consumption and thread usage. You can load-balance your services by running a cluster of servers and each server will be able to process any request independently without consuming any memory to store the state, and then release all resources such as threads or database connections after the request has been processed. The downside, however, is that you will have to pass the entire state along with each request. This may not be a problem if your state is always relatively small, such as read/query operations or simple updates that are performed as one unit of work. In large systems and enterprise applications though that require multiple levels of validations before the data can be saved, the user state may contain numerous edits that span multiple objects. Designing a service that can take all the user edits in a single request can be a very challenging task in this case, and you will likely need to design a separate service or operation for every different scenario, which will make your services not reusable and may eventually lead to a maintenance nightmare. Read more: Codeproject
QR:
Posts
0 comments:
Post a Comment