Timeline for How to abstract the data layer when using Spring Data?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 4, 2019 at 21:05 | vote | accept | abstract christmas tree | ||
| Jul 4, 2019 at 21:05 | comment | added | abstract christmas tree | Yeah, I see the confusion about my use of the term "framework agnostic". I used the persistence layer, which is implemented using that framework, as an example, it's not my focus. But I do agree that my specific example leans very close to overengineering while changing databases probably means altering the implementation of the business logic anyway. It's all nice in theory but probably very expensive in practice :) Thanks for the answer, marking it as resolved. | |
| Jul 4, 2019 at 20:58 | comment | added | Kayaman | @KevinStrijbos see my edit. | |
| Jul 4, 2019 at 20:58 | history | edited | Kayaman | CC BY-SA 4.0 |
added 1804 characters in body
|
| Jul 4, 2019 at 20:14 | comment | added | abstract christmas tree | Modified my question. | |
| Jul 4, 2019 at 18:05 | comment | added | Kayaman | Partly yes. Generally the business logic is in facade and service layers, but depending on project size some layers might be left out. It's not really worthwhile adding a layer between the service layer and the DAL (repositories) because the service will have to have some clue about implementation details (besides, higher layers are allowed to know about lower layers, the other way around is more problematic). If you can come up with a situation where you think an additional layer would provide advantageous, add it to your question and I'll dissect it. | |
| Jul 4, 2019 at 17:47 | comment | added | abstract christmas tree | Thanks for the explanation. But shouldn't the service layer contain the business logic? The controller calls the service, which contains the business logic, which uses the data layer. That's how I've always done it, is that the wrong way? | |
| Jul 4, 2019 at 17:36 | comment | added | Kayaman |
@KevinStrijbos Since you're writing a game, a standard approach is to write a game engine and then the game would depend on the engine (and not how the engine is implemented). But that's a different task, and you probably would not get any advantages (reusability, ease of development) in your case. You have to rely on some things to write any worthwhile code. Besides, your business logic shouldn't know/care about Spring. It just knows that BoardService.movePiece() moves a piece. The service implementation can be switched if needed.
|
|
| Jul 4, 2019 at 17:14 | comment | added | abstract christmas tree | How so? If I just use Spring to wire the beans in my business logic, the dependency would be very much okay in my eyes. Relying on specific contracts Spring Data provides sounds worse or is it just me? | |
| Jul 4, 2019 at 17:07 | history | answered | Kayaman | CC BY-SA 4.0 |