Timeline for How to model Business Objects depending on use cases?
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 24 at 22:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| May 27 at 21:04 | history | bumped | CommunityBot | This question has answers that may be good or bad; the system has marked it active so that they can be reviewed. | |
| Jan 6, 2023 at 12:00 | history | tweeted | twitter.com/StackSoftEng/status/1611331756354854913 | ||
| Aug 26, 2020 at 16:33 | history | edited | Christophe |
edited tags
|
|
| Aug 26, 2020 at 11:49 | comment | added | Laiv | Run away from "generics". Some ppl is too obsessed with making everything generic or abstract. Concreteness is not the Evil! Let abstractions emerge! | |
| Aug 25, 2020 at 14:08 | answer | added | Christophe | timeline score: 0 | |
| Aug 25, 2020 at 13:02 | comment | added | Bart van Ingen Schenau | For the bidirectional relation, you don't need lazy loading. You just need some caching so that when the user asks for Bill#42 and the associated pallet does the same for establishing the relation, that both get the exact same object. And the cache should already provide that object while its relations are being built. | |
| Aug 25, 2020 at 12:12 | comment | added | Filip Milovanović |
BTW, those use case–specific classes would have methods that would return something like your BillWithPallet class, so you'd define that in the BLL as well, but consume it from your Presentation layer. That said, once you have that outer shell, depending on how you conceptualize it (e.g., if your classes return something like BillWithPallet or BillWith[SubsetOfPalletProps]), it may no longer be necessary to remove the Bill-Pallet relationship, and then you can go with the direction that makes more sense according to your understanding of those business concepts. 2/2
|
|
| Aug 25, 2020 at 12:12 | comment | added | Filip Milovanović | "The problem in this case is that in my BLL I would have very specific classes, so it would become a less generic layer" - BLL is not supposed to be a very generic layer, and in fact use case–specific classes should form an outer "shell" of the BLL. This layer captures the business logic specific to the problem domain, and it's only generic to the extent that it supports two or more related applications dealing with roughly the same domain, but that comes later on when the system is more mature (if at all). 1/2 | |
| Aug 25, 2020 at 8:56 | review | First posts | |||
| Aug 26, 2020 at 2:16 | |||||
| Aug 25, 2020 at 8:49 | history | asked | Ivan | CC BY-SA 4.0 |