Ostatnio znalazłem taki kod. Nie rozumiem kilku rzeczy:
- Po co jest tworzony interfejs
IEmailConfiguration
?
No przecież jest napisane: Since we are good programmers we will use an interface too!
. :P Osobiście przestałbym czytać po tym zdaniu, tak na wszelki wypadek.
Ogólnie interfejs do konfiguracji to nie jest zły pomysł, tylko jeśli chcemy iść tą drogą, to tam powinny być metody , a nie właściwości z publicznymi setterami. Publiczny setter w interfejsie to jakiś absurd.
Ja bym zrobił raczej interfejs IConfigurationProvider
, który by mi zwracał EmailConfiguration
jakąś metodą. Ale tylko gdybym musiał, bo tak ogólnie, to konfigurowalny w taki sposób serwis do obsługi emailów nie ma za bardzo dla mnie sensu.
I czy takie pchanie klasy konfiguracji do warstwy aplikacji jest w porządku? Jak dla mnie, powinno się jej używać jedynie przy rejestrowaniu zależności do skonfigurowania jakiegoś EmailClienta.
No właśnie nie. Taki interfejs daje tylko to, że można jednostkowo przetestować kod EmailSerwisu, ale testowanie takiej klasy jednostkowo nie ma przecież żadnego sensu.
- Dlaczego
SmtpClient
nie jest zarejestrowany w kontenerze i wstrzykiwany, tylko tworzony "dynamicznie" za pomocą using
?
Wtedy byś wypychał szczegóły implementacji do warstwy aplikacji. Jest to w porządku? ;)
Osobiście bym tak nie robił. Żadnego zysku z tego nie ma, to jakiś szczegół implementacji EmailService. Inne klasy powinny po prostu korzystać z tej klasy, która konfiguruje bibliotekę do obsługi emaili na swoje potrzeby.
Ma to związek z wydajnością? Czy wywołanie Dispose
nie może poczekać? Jeśli użyjemy AddScoped
, to przecież taDispose
zostanie wywołana tuż po zakończeniu przetwarzania żądania.
A jeśli poleci wyjątek, to też zostanie dispose zawołane?