3 svar · 434 visningar · startad av Lukaspojken
Någon gång denna veckan såg jag nedanstående kod och skulle vilja fråga vad ni tycker om det.
//För delete
new OrderService().DeleteByID(order.ID);
//För hämtning av order
Order order = new OrderService().GetByID(order.ID);
Vad tycker ni om det? Jag har gjort enligt följande i princip alltid men jag tror jag gillar lite ovanstående.
//För delete
OrderService orderService = new OrderService();
orderService().DeleteByID(order.ID);
//För hämtning av order
OrderService orderService = new OrderService();
Order order = orderService.GetByID(order.ID);
Om man har flera metodanrop till OrderService då är en deklaration nog att rekommendera men i annat fall tror jag man klarar sig rätt bra utan. All feedback välkomnas!
Nu är det ju förvisso ingen som helst skillnad på det övre och det undre exemplet mer än att du delat upp det nedre på två rader (och att orderService().DeleteByID.... skulle generera ett syntax error). Men som du säger, om du ska använda OrderService-objektet mer än en gång så är det ju rimligt att inte instansiera det flera gånger.
DeleteByID och GetByID skulle kunna vara statiska metoder också men bara för den som inte bryr sig om testning. ;)
Det är väl mest en fråga om stil annars.
DeleteByID och GetByID skulle kunna vara statiska metoder också men bara för den som inte bryr sig om testning. ;)
För Java finns det verktyg för att mocka statiska metoder! :)
Jag har ju blivit såld på dependency injection containers så jag hade aldrig behövt tänka sådär. Jag di containern skickar in allt som klassen behöver via konstruktorn så att det inte behövs någon new någonstans i klassen. Gör min kod mer löskopplad om jag använder mig av interface, i och med löskopplingen blir min kod lättare att testa, eller lättare att använda mig av mockningar medans jag utvecklar och med hjälp av DI-containernen behöver jag aldrig göra t.ex.
var orderViewModel = new OrderViewModel(new OrderRepository(databaseConnection));
Eftersom allting sköts av di containern, di containern vet vilka instanser den bara skall skapa en gång, t.ex. di containern kan hålla koll så att den inte öppnar mer än en databaskoppling på ett webrequest, på det sättet slipper man tänka på applicationens states för det ligger och sköts av di containern.