Archief - [PROG]Java Hibernate / Spring, business logic

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
K

KevinMa

Legacy Member
Na wat met Hibernate en Spring te spelen, zit ik met de vraag waar ik best de business logic plaats. Een schetsje van mijn probleem:

Stel: ik heb een Auction class (mapped naar db table), die door een AuctionDao class met Hibernate wordt opgehaald. Die Auction class heeft een placeBid() method die de logica bevat om een bod te plaatsen. Andere classes kunnen deze Auction class extenden en de placeBid() method overriden, tot zover geen probleem. Het probleem is dat ik in die placeBid method DAO classes wil aanspreken, wat zou willen zeggen dat voor elk Auction object dat wordt opgehaald uit de db, Spring de dao's zou moeten "wiren". Dit lijkt mij echter niet de beste oplossing. Iemand ervaring met dit, of een gestandardiseerde oplossing?
e

eniac

Legacy Member
Dus Auction is eigenlijk een model class? Goh, dan zou ik die eigenlijk de dao's niet laten aanspreken tbh. Ik vind het niet aangeraden om business logica in je model op zich te steken.

Doorgaans heb je een view -> business logics -> DAO structuur (waarbij DAO business niet kent, en business kent de view niet), met het domeinmodel dat hier los van staat en door alle lagen gebruikt wordt. Domeinmodel = domme beans, zodat veranderingen in je logica geen veranderingen in je domein hoeven te veroorzaken.

Dus, concreet: kan je geen soort van AuctionManager maken die aan een Auction object opvraagt hoe dat bod te maken, en deze AuctionManager dan de DAO's laten aanspreken? Dan hoef je in Spring enkel aan de AuctionManager een AuctionDao mee te geven.

Veel meer kan ik voorlopig niet zeggen want ik heb niet echt een zicht op wat je applicatie moet doen :)
B

Bavo aka Joske

Legacy Member
Dit lijkt sterk op businesslogica, en het ziet ernaar uit dat dit simpelweg kan opgelost worden in een service, zoals eniac zegt. Je kan best verschillende auctionobjecten maken in uw domein, en in de service beslissen welke logica uit te voeren aan de hand van welk domeinobject.

Dus:
- Auction (domein)
- SimpleAuction (domein)
- MultiAuction (domein)

- AuctionService (service)

AuctionService doet verschillende logica adhv een instanceof. Of via een Manager of Factory die adhv het meegegeven object een service teruggeeft die specifiek de juiste logica implementeert

dat is niet wat OO moet zijn jammer genoeg, en dat is het resultaat door de 'aenimic' modellen. Beter zou zijn een rich domain model op te bouwen waar idd uw domeinobjecten zelf zaken gaan beslissen. Je mag dan gerust resources injecteren. Weet wel dat je best weet wat je doet, en velen het gaan afkeuren.
K

KevinMa

Legacy Member
Door gebruik te maken van een Service die adhv een instanceof de juiste logica toepast, maakt dat inheritance eigenlijk toch overbodig? De service kan dan even goed checken op de desbetreffende property. Alle logica in services zetten is ook een beetje faux pas, niet?

Wat als ik AuctionService de DAO's laat aanspreken en zo de nodige info ophaal, en daarmee dan placeBid() van Auction oproep (en de implementatie van Auction die dan de correcte logica implementeert).Auction (of eender welke implementie ervan) hoeft niets te weten van Services/DAOs, en AuctionService hoeft niets te weten van het plaatsen van een bod.
Is dit misschien de beste oplossing?
e

eniac

Legacy Member
Wat moet er eigenlijk gebeuren in die placeBid() methode? Wordt er een soort Bid object gemaakt ofzo? Want dan is het wel heel eenvoudig: je vraagt in de AuctionService een Bid object op via de placeBid() methode, en saved dat naar de database.

Auction (of eender welke implementie ervan) hoeft niets te weten van Services/DAOs, en AuctionService hoeft niets te weten van het plaatsen van een bod.
Klik om te vergroten...

Wat je hier beschrijft is wat mij betreft alleszins wel een doel om alles proper te houden.
B

Bavo aka Joske

Legacy Member
eniac zei:
Wat moet er eigenlijk gebeuren in die placeBid() methode? Wordt er een soort Bid object gemaakt ofzo? Want dan is het wel heel eenvoudig: je vraagt in de AuctionService een Bid object op via de placeBid() methode, en saved dat naar de database.
Klik om te vergroten...

Dat is een elegante oplossing. Zolang je natuurlijk vrede neemt dat er weldegelijk business logia in je domein zit, sommige mensen houden domein puur als Data Transfer Objects en verwachten geen logica erin buiten utility methodes zoals conversie. Maar het kan zeker vanuit OO perspectief.
I

Ice

Legacy Member
KevinMa zei:
Door gebruik te maken van een Service die adhv een instanceof de juiste logica toepast, maakt dat inheritance eigenlijk toch overbodig?
Klik om te vergroten...

Zoiets zou ik dus NIET doen, je kan dan achteraf nameljks niets toevoegen zonder die 'instanceof' checks allemaal aan te passen EN het druist wel in tegen elk OO principe.

Aangezien wij niet weten wat placeBid juist doet, is het natuurlijk ook moeilijk om een degelijke oplossing voor te stellen.
Enige uitleg wat de meerder soorten auctions doen, is msch ook handig ;)

Waar je alles steekt qua logica en DAO kan je eeuwig over blijven discussieren natuurlijk.
Probeer de dingen zoveel mogelijk gescheiden te houden ,maar maak het niet te complex. Een oplossing kan zijn:
Auction: POJO model object, met eventueel wat utility methods
AuctionDAO: DAO... duh :p
AuctionManager of (AuctionController): Business logic + retrieve/search methods

ps. Afhankelijk van wat uw subklassen van Auction juist doen, is het msch handig om eens naar http://en.wikipedia.org/wiki/Decorator_pattern te kijken.
W

WHiSPy

Legacy Member
Ice zei:
Zoiets zou ik dus NIET doen, je kan dan achteraf nameljks niets toevoegen zonder die 'instanceof' checks allemaal aan te passen EN het druist wel in tegen elk OO principe.

Aangezien wij niet weten wat placeBid juist doet, is het natuurlijk ook moeilijk om een degelijke oplossing voor te stellen.
Enige uitleg wat de meerder soorten auctions doen, is msch ook handig ;)

Waar je alles steekt qua logica en DAO kan je eeuwig over blijven discussieren natuurlijk.
Probeer de dingen zoveel mogelijk gescheiden te houden ,maar maak het niet te complex. Een oplossing kan zijn:
Auction: POJO model object, met eventueel wat utility methods
AuctionDAO: DAO... duh :p
AuctionManager of (AuctionController): Business logic + retrieve/search methods

ps. Afhankelijk van wat uw subklassen van Auction juist doen, is het msch handig om eens naar http://en.wikipedia.org/wiki/Decorator_pattern te kijken.
Klik om te vergroten...

Frons? Business logic in je controller? Blasphemy!

Bekijk de voorbeeldapplicaties die bij spring komen eens? ;)

Structuur die ze bij spring gebruiken:
jsp - controller - service - dao

Allemaal mooi gewired via de context-files en met gebruik van bv de HibernateDaoSupport in de DAO's. :)
B

Bavo aka Joske

Legacy Member
Denk niet dat hij dat perse bedoelde, dat het de controller is in een MVC-applicatie. Eerder een 'service' met de rare naam controller. Want waar slaat 'manager' op? :)
I

Ice

Legacy Member
Zie, ga in 10 verschillende bedrijven werken en ge gaat 10x een ander naamgeving tegenkomen. Wat ik met 'Manager/Controller' bedoelde was dus niet het stukje controller in het MVC stuk maar eerder een 'service' 'laag'.
Probleem met software is, er is niet 1 juiste manier, er zijn echter wel veeeel foute manieren :p
d

dJeez

Legacy Member
Troost u Ice, bij ons zijn de "services" ook Manager classes (bij het Spring project dat ik heb geërfd) :p.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan