上一章 Day 13 - 什麼是IOC控制反轉? 什麼是DI依賴注入?
今天要用Service層來示範如何實作
在專案下新增一個Service資料夾, 並在其底下新增一個Interface
MemberService.java
public interface MemberService {
public Member saveMember(Member member);
}
然後在Service資料夾底下再新增一個impl資料夾
新增MemberServiceImpl.java
@Service
public class MemberServiceImpl implements MemberService {
@Autowired
private MemberRepository memberRepository;
@Override
public Member saveMember(Member member) {
member.setMid(UUID.randomUUID().toString().replaceAll("-", ""));
member.setCreateTime(new Date());
memberRepository.save(member);
return member;
}
}
結構大概是這樣
修改一下我們的MemberController
@RestController
@RequestMapping("/api")
public class MemberController {
@Autowired
private MemberRepository memberRepository;
@Autowired
private MemberService memberService;
@GetMapping("/members")
public Collection<Member> members() {
return memberRepository.findAll();
}
@GetMapping("/member/{id}")
public ResponseEntity<?> getMember(@PathVariable Long id) {
Optional<Member> member = memberRepository.findById(id);
return member.map(response -> ResponseEntity.ok().body(response))
.orElse(new ResponseEntity<>(HttpStatus.NOT_FOUND));
}
@PostMapping("/member")
public ResponseEntity<Member> createMember(@Valid @RequestBody Member member) throws Exception {
Member result = memberService.saveMember(member);
return ResponseEntity.ok().body(result);
}
@PutMapping("/member/{id}")
public ResponseEntity<Member> updateMember(@Valid @RequestBody Member member) {
Member result = memberRepository.save(member);
return ResponseEntity.ok().body(result);
}
@DeleteMapping("/member/{id}")
public ResponseEntity<?> deleteMember(@PathVariable Long id){
memberRepository.deleteById(id);
return ResponseEntity.ok().build();
}
}
可以看到我們是以@Autowired的方式, 注入MemberService, 讓Spring幫我們管理
現在我們增刪查改功能全都有了, 目前為止都是用H2 Database
下一章正式進入MySQL Database
Day 15 - MySQL 手動建立Schema與Table
不是用 service 來操作 Dao 層嗎 ? 大大怎麼只把 新增
放到 service 裡面,其他還是放 controller;不將 CRUD
都放在 service ?
以往我們都會有Controller -> Service -> Dao, Service層主要放business logic,
但隨著前後端分離, 可以看到有些API僅需傳遞資料, 已無任何商業邏輯, Controller也不再負責導頁, 這種情況下是否還需要多過一層Service?
目前是看到兩種寫法都有, 有人認為不需要多過一層, 有人認為全部放Service層好管理, 這取決於你專案的規範與大小,
小型輕量的專案可以省略, 但若是多人大型專案, 則需要統一規範與寫法。
這還是得看這個動作是「讀」還是「寫」。如果是「寫」,那就會牽扯到系統狀態的改變,需要請出 service 來做流程管理,entity 來做核心邏輯實現,最後 repository 或 dao 來做資料持久化。
如果在「寫」的過程中,感覺特別簡單,也許是運氣很好,邏輯就真的這麼簡單,也有可能是設計時沒有把「商業邏輯」帶進來,只是單純在做CURD而已。如果是後者,那也許可以考慮改用更能表現商業邏輯的街口設計。
如果是「讀」,就無所謂,反正不會動到系統狀態,就不用啟動領域物件來幫忙了,儘管在最外層讀了資料吐回去便是。
當然以上是小弟個人觀點啦 :)