Timeline for What is business logic code and what is data access code, and what's the difference?
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 16, 2022 at 0:59 | comment | added | wonsuc | Very great answer. | |
| Jul 6, 2015 at 16:31 | comment | added | Rogério | Actually, the implementation of findByCustomer is as simple as return performQuery("select o from Order o where o.customer = ?1", customer). And if the assocation exists in the domain model, we could simply have orders = customer.getOrders(). | |
| Jul 6, 2015 at 16:12 | comment | added | Thomas Junk | As I said, the boilerplate-part is obfuscated: orderRepository.findByCustomer(customer); does the boilerplate part in the background. »why shouldn't they both be considered as businnes logic methods« because they are only written do get data. The purpose is part of the business logic. | |
| Jul 6, 2015 at 15:48 | comment | added | Rogério | There is no boilerplate code in my example. If retrieving only active orders is a business rule, as we both agree, and since both of my methods implement it, why shouldn't they both be considered as businnes logic methods? | |
| Jul 4, 2015 at 16:40 | comment | added | Thomas Junk | In your example the boilerplate part is obfuscated. You are using the repository pattern to actually retrieve the data. The fact, that you apply additional filtering is in your case neglectable. You only retrieve data. The reason why you retrieve only active order is a business rule. The filtering either via db or javaside is only an implementation detail,but is as such no logic. | |
| Jul 4, 2015 at 15:00 | comment | added | Rogério | Now for the "business logic code". You say it is responsible for things like b.1) "transform data", b.2) "contain the [business] rules", b.3) "[decide] when to retrieve data". And I agree with that; this is what business code is about. Just note that both my example methods do precisely these things: b.1) they add values to produce a total (a form of data transformation), b.2) they contain the business rule that only active Orders should be considered, and b.3) they know that customer order data needs to be fetched from persistent state for it to be filtered and summed up. | |
| Jul 4, 2015 at 14:49 | comment | added | Rogério | Ok, you say that the methods I wrote in the question are "data access code". But you yourself described it as code to: a.1) "open a connection to a DB", a.2) "retrieve data [from the DB]", or "do OR-mapping". However, both methods do none of these things! DB connections, OR-mapping, and the actual data retrieval is handled by the JPA (ORM) implementation (a 3rd-party library) - there is OR-mapping metadata in entities, of course, but that's separate. The ORM implementation does all the SQL generation and executes all the JDBC code that actually communicates with the DB server. | |
| Jul 4, 2015 at 7:34 | history | answered | Thomas Junk | CC BY-SA 3.0 |