How to make yourself realize the existence of Service interface?
junior internship, graduating more than half a year, taking over some small projects, the existence of the service interface in the current project makes me feel a little bit.
pain in the egg.
maybe it"s because the outsourcing company is survival-oriented, and it"s also the reason why I haven"t come into contact with large and complex projects
.
current experience:
1.service interface
Controllerserviceservicerun...
...
......
again and again...
what I want to ask is not the function of the interface. I want to ask, what can make me feel the existence of the service interface in a small and simple project, make me think it is not bad, rather than become a kind of encumbrance?
2.Controller
:Controller
serviceControllerserviceControllerservice
...
if not, it is acceptable to get a conclusion that the specification is for the sake of the development specification. After all, the development specification is also very important
.
these are my two confused areas. I hope the boss will share his opinions. Thx
I generally respect
when I write code.
all codes, frameworks or specifications should conform to the current business architecture
there are no best, only those that are most in line with the business, because those so-called specifications, or frameworks, are not imagined by others, and it is precisely because of my above sentence, it is because the actual business use process does encounter problems, want to avoid problems, want to solve the problem will create some rules and regulations, with these constraints will not be easy to make mistakes, so that it is easier to implement the function more efficiently
so when your business uses certain constraints or frameworks, there's nothing to worry about, just do it in the way that best improves your work, because when the real existing way of working begins to dissatisfy your previous ideas, you will find a way or look for an existing solution
take a bad chestnut, if I am very thirsty and have a glass of water in my hand, I can quench my thirst by drinking it directly, but I have to boil it like others first, then add sugar to drink, and say why it is so sweet (cover my face). No, no, no. ), because your need is to quench your thirst, heating and adding sugar is the solution to the needs of others
The
emmm, example is not very good. Excuse me, for reference
this is the development specification. Writing some shared business logic into service
is actually quite scary, especially in small projects. It's just a specification.
with service interface, the expected result is that the interface is defined and standardized, and various implementations can be easily selected and replaced, but in actual development, it is rare to expand on a complete project. Even if the interface is extended, in most cases, the interface also needs to be extended.
We need to modify a service implementation class, so there are far more cases of modifying the service interface than just modifying the implementation, and using the interface affects efficiency. If it is a small project, it does not need to be superfluous at all, not even the entity class.
for small projects, if the company does not have code review, which layer you write is not a big problem, it can only be said to be a specification, and there is no way to write the business code so clearly that the service should be returned to the controller layer, as much as you like
1. With regard to the service layer, it is common to write the interface first and then the implementation. But I don't think this kind of situation is necessary. We know that the interface is actually used for business polymorphism, such as sending service may have SMS, email and so on. It is reasonable to use the interface declaration and then the concrete method to implement it. But if a business has only one form, you can omit the interface and write the specific class directly.
2. With regard to the controller layer, the controller layer should be a layer that interacts with the outside world, and the business logic is not included. If he interacts with the outside world, then he should be responsible for things related to the interaction with the outside world. Such as parameter verification. Business logic should be kept in service
AOP,MVC--Spring learning and reflection on CodeIgniter-QueenKing-SegmentFault think no: https://codeshelper.com/a/11.
rpc, you can't let controller expose the service
.
