Application Framework Combat 35: Service Overview

The previous article introduced my knowledge of several entities, and this article will cover the usage of several services.

Preview this series of follow-up plans, this post, ready to enter the actual combat drill stage, first describes how to quickly solve crud operations, from how to use PD data modeling to use Codesmith generate code, first take you to feel, and then come back to introduce the inner elements of the framework, so as not to be sleepy when reading.

Introduction to Application services

For a new design element, you can assume that you do not need it until you really recognize its role and then introduce it. So, what are the benefits of application services?

App Service helps simplify presentation operations

In the case of MVC, if there is no application service, then the controller will call the warehouse directly, set the query condition, convert the DTO and so on.

When the controller operation becomes complex, you will find a way to separate the controller code. The best way to separate the controller code is to set up the corresponding application service, not to easily separate the controller itself, because it makes it difficult to find the view and destroys the contract, resulting in higher maintenance costs.

App Service provides a unique API access point for the presentation layer

When a controller operation becomes complex, the programmer writing the controller needs to know more about what aggregation, Domain Services, infrastructure services, and other construction elements are assembled, and what is the order of the calls?

Is this a question that the presentation layer should be concerned about?

The presentation layer should only be concerned with the display of the interface, which is the basic responsibility of the presentation layer and other duties as far as possible to the rear.

App Service packages fine-grained operations into coarse-grained operations, so that programmers who write the presentation are no longer looking around, he just has to remember one thing: the need to access any back-end operations, to find application services is right.

application services reduce redundant code for multiple presentation tiers

If you need multiple presentation layers, such as the need to develop a WPF program that is exactly the same as MVC, you will find that the presentation layer is flooded with repetitive code.

With the introduction of application services, the presentation layer code is more concise, with less redundant code and easier to create multiple presentation layers.

Application service integration and assembly domain layer and infrastructure layer

In order to maintain the purity of the domain layer, we adopt the dependency inversion principle, the domain layer only has the operation interface, the concrete realization but at the infrastructure layer, must finally be able to run, had to assemble them together.

If there is no application service, the controller will need to assemble itself, which increases the burden of the performance layer, application services to undertake this work, let the performance layer to concentrate on their own job.

application services with DTOs to optimize remote call performance

When using a distributed architecture, in order to improve performance, you need to minimize the number of remote calls.

App service acts as a remote façade in a distributed environment, working with DTOs to solve this problem.

comparison between application services and the BLL

For a long time to adopt the traditional three-tier architecture of friends, for the application of services this structure is extremely cordial, initially used up, you find this application service is the BLL replica.

The BLL is the business logic layer of the traditional three-tier architecture, and many people use the BLL directly to name the service class of the business logic layer, which I use for the time being.

The BLL is the place where business logic is placed, the BLL saves the results to the model entity class, and then passes the entity classes to the other layers.

Application services are used to coordinate the operations of the domain layer and infrastructure layer, and the application service itself should not complete complex business logic.

The key difference between application services and the BLL is that the BLL directly completes the business logic, while application services entrust the business logic to domain entities or Domain Services.

In code, the BLL handles the business logic primarily by manipulating the properties of the model, while the application service accomplishes all the business operations by invoking the domain entity or domain service method.

Field Service Introduction

From the previous introduction, you should have found that application services are useful, and then take a look at the Domain Services below.

Ideally, all business logic should be highly cohesive into the aggregation. But for more complex businesses, there are generally more complex processes in which the control of these processes is not appropriate because these behaviors do not belong to an aggregation.

Putting these behaviors into application services can lead to complex application services and the separation of business logic from the domain layer, making business logic more difficult to manage.

In order to re-move the business logic back to the domain layer, a domain service needs to be added.

Now that we have two construction elements for application services and Domain Services, which part should be put into the application service for a complex operation, and which will be put into the domain service?

The book introduces that the business logic can be divided into domain logic and application logic, domain logic should be put completely to the domain layer, can not be leaked to other layers, and application logic should be placed in the application layer services.

As you can see, that is quite abstract, which is the domain logic, which is the application of logic? This is difficult to classify accurately.

A classic example of application logic is transaction control, where transaction control is not a customer's requirement, but it is very important, so put this stuff in the application layer, not the domain layer.

Is the operation of e-mail the domain logic or the application logic?? Some say it's domain logic, some say it's application logic, and others say it depends on the situation. There are so few opinions that you can't touch your head.

However, the purpose of our study is not to conduct academic debates, but to effectively improve the maintainability of the project, so do not pay much attention to the concept of IQ, the following talk about my usage.

For application services, I always need it because it simplifies the presentation layer development.

For some of the simpler business logic, I put it directly into the app service if I found that the domain service was not generating much value. For example, to determine the name of an entity can not be duplicated, this is a business requirement, first of all consider this business logic could be put into the entity? No, because the entity itself cannot understand that its name has no duplicates. Second, consider the need to establish Domain Services? For this simple business logic, creating a domain service is a bit of a cannon hit with a mosquito sensation. I'm going to put the duplicate name detection directly into the app service, although there's a bit of business logic scattered across the application layer, but I don't see any impact on maintainability.

If the business logic is more complex, I will generally use TDD to promote business development, in this case, the establishment of Domain Services is an excellent choice, because the domain layer relies on low, unit testing more convenient.

Regardless of the application service or domain service, the basic principle of development is to entrust the business logic to the domain entity as much as possible, and the service only does the dispatching work.

Infrastructure services A good understanding is to provide some basic support services, such as sending mail and other operations.

need to extract interfaces for the service?

Learning design patterns requires us to interface-oriented programming, but some object gurus do not recommend over-design, to avoid unnecessary complexity, in the "Implementation domain-driven design" book, application services using a separate interface does not benefit.

Although the interface has a lot of functions, but generally speaking, the real demand to drive the creation of interfaces comes from polymorphism. In the general project development, especially in the early stage, the service rarely has the polymorphic demand, then we also need to establish the interface for the service?

In the absence of ReSharper, I used the interface very carefully, because it is very difficult to locate the implementation class from the interface, but since the use of ReSharper, the interface is no longer an obstacle.

On the other hand, the use of the IOC framework makes the use of interfaces even more pervasive, and I just need to bind the implementation class to the interface, which is freely available in the program. Although the IOC can bind the implementation class directly, it feels a bit strange.

Finally, for cross-layer access, the adoption of interface interconnection also conforms to the layered design principle.

For the use of the IOC framework, and the installation of ReSharper such a powerful tool, the interface will not cause you any inconvenience, as to whether to lead to complexity, you need to experience.

The use of interface programming in code may not yield substantial benefits in most cases, but in the event of a change in requirements, it is only necessary to modify the IOC configuration to replace the relevant implementation, which is not cost-effective.

Service Naming Conventions

When both application services and Domain Services are required, it can be difficult to find a service name. such as user management, application services called UserService, if the need for domain Services, also called UserService conflict, but the name of the other may not be appropriate.

My approach is that the application service is unified to the end of the service, Domain Services are unified with the manager end, so that the problem can be easily solved. It may be particularly useful for English novices like me.

Latest source Code release

This update features Easyui table columns binding Combox and Combotree. At the same time, a new icon management module, which contains the Baidu Webuploader upload image control of the simple package, service-side upload operation package.

The Webuploader control is very powerful, and the demo is very easy to use, I basically directly copy the simple modification on it.

I've provided some icons in the data download package to make it easy for everyone to work with.

At the same time, this example contains Domain Services and provides relevant unit tests that you can refer to.

Download the section to run a few.

Although this interface contains the CRUD operations of the tree control, the total number of JS code is still relatively small.

when downloading, please remember to recommend :

Http://files.cnblogs.com/files/xiadao521/Applications.2015.4.8.1.rar

Http://files.cnblogs.com/files/xiadao521/Framework.2015.4.8.1.rar

Http://files.cnblogs.com/files/xiadao521/Data.2015.4.8.2.rar

. NET Application Framework Exchange QQ Group: 386092459, welcome interested friends to join the discussion.

. Net Easyui Development of QQ Group (Easyui developers only, non-Easyui developers not to enter): 157809322

Thank you for your continued attention, my blog address: http://www.cnblogs.com/xiadao521/

Application Framework Combat 35: Service Overview