Jakiej konwencji nazewnictwa używasz dla warstwy usługi w aplikacji Spring MVC?

Question

Utknąłem z ustaleniem dobrej konwencji nazewnictwa dla warstwy usługowej w aplikacji wiosną. Dla każdej klasy w warstwie serwisowej najpierw piszę interfejs, który powinien zaimplementować, a następnie rzeczywistą klasę. Tak na przykład mam następujący interfejs:

public interface UserAccountManager{ 
    public void registerUser(UserAccount newUserAccount); 
    public void resetPassword(UserAccount userAccount); 
... 
} 

a następnie klasę implementacji ...

Co robaki mnie Oto UserAccountManager to dobra nazwa dla klasy implementacji więc jestem zmuszony do oddania go głupia nazwa jak SimpleUserAccountManager lub UserAccountDbManager. Jakie są niektóre z dotychczasowych konwencji? Czy dobrze jest umieścić klasy implementacji w innym pakiecie i nadać im takie same nazwy jak interfejsy? Co sądzisz o używaniu nazw kończących się na Menedżerze zamiast nazw kończących się na Usługach?

Answer 1

Sama sprężyna podaje interfejsy nazw rodzajowych, a następnie podaje klasy w oparciu o szczegóły implementacji. Jest to jeden przykład, który przychodzi na myśli:

interface: Controller 
abstract classes: AbstractController, AbstractCommandController, 
        SimpleFormController, MultiActionController 

Nie sądzę nazwy takie jak SimpleUserAccountManager lub UserAccountDbManager są głupie, bo oni przekazać jakąś informację dotyczącą realizacji menedżera/usługi.

Co znajdę głupi jest wspólna konwencja dodanie przyrostka „IMPL” na zajęciach realizacji:

my/package/UserAccountManager 
my/package/impl/UserAccountManagerImpl 

Niektórzy ludzie wolą to jednak.

Answer 2

czuję, że usługi vs. Menedżer nazewnictwa przyrostek jest czysto preferencji. Jedyny przypadek, w którym "Usługa" kiedykolwiek spowodował zamieszanie, ma miejsce wtedy, gdy usługi sieciowe są dostępne na warstwie usług. W przypadku niektórych projektów po prostu odnosiliśmy się do klas usług internetowych jako brokerów, ponieważ wszystko, co robili, służyło do tłumaczenia lub pośrednictwa wywołania usługi sieci Web w wywołanie naszej warstwy usług.

Zgadzam się z kgiannakakis, że dodanie sufiksów przy pomocy "Impl" nie jest dobrym podejściem. Natknąłem się również na kodowanie najlepszych praktyk, które wspominają, że tego nie robią. Nazywanie interfejsu po abstrakcji jest ogólnie przyjętą najlepszą praktyką. Nazewnictwo klasy implementacji po interfejsie z pewnym wskaźnikiem jego przeznaczenia lub typu, jak sugeruje firma kgiannakakis, wydaje się być ogólnie przyjętym podejściem.

Gdy mamy oparte na sieci Web DAO i DAO bazujące na ORM, używamy zarówno pakietów, jak i nazw klas, aby odróżnić klasy implementacji od ich interfejsów i od siebie nawzajem. Myślę, że umieszczenie implementacji w różnych pakietach sprowadza się do tego, ile klas posiadasz w pakiecie, jak różnie są one implementowane i jak bardzo chcesz dzielić sprawy.

Answer 3

Na przykład dajesz, bym używać nazw wdrożeniowe, które odzwierciedlają jak klasa wykonuje operacje, takie jak HibernateUserAccountManager lub JPAUserAccountManager lub JDBCUserAccountManager, itp, albo po prostu UserAccountManagerDAO.

Answer 4

Można również nazwać interfejs IUserAccountManager (ta konwencja jest używana na przykład w Eclipse RCP), a następnie użyć UserAccountManager dla domyślnej implementacji.

Answer 5

Oto czego używamy:

• XxxDAO (Data Access Object) - odpowiedzialny za interakcję bezpośrednio z EntityManager, JDBC źródła danych, system plików, itp powinna zawierać tylko logikę trwałości, takie jak SQL lub JPA-QL, ale nie (lub tak mało jak to możliwe) logiki biznesowej. Powinien być dostępny tylko od Managers.
• XxxManager - Zarządza obiektami na poziomie biznesowym, zwykle wykonuje operacje CRUD, ale dodaje wymaganą logikę biznesową.
• XxxService - Warstwa, w której znajduje się logika biznesowa. Powinien "mówić" w prostych obiektach - łańcuchach, wzorcach itp. - w miarę możliwości.
• XxxController - Warstwa interakcji UI. Powinien rozmawiać tylko z usługami.
• XxxUtilities/XxxUtils - Pomocnicze metody bezstanowe, nie powinny zależeć od żadnej usługi w systemie. Jeśli potrzebujesz takiej sependencji, przekonwertuj klasę narzędziową na usługę lub dodaj wynik usługi jako parametr.

Dla realizacji dodamy przyrostek IMPL (XxxServiceImpl) do odrębnego niego z poziomu interfejsu, a jeśli istnieje kilka implementacji lub chcemy dodać dodatkowe informacje, możemy dodać go jako prefiksu (JdbcXxxDaoImpl, GoogleMapsGeocodingServiceImpl itp). Nazwy klas stają się w ten sposób nieco dłuższe, ale są bardzo opisowe i dokumentują się samemu.

Answer 6

Oczywiście nie jest ważne, czy nazwy klas kończą się na Manager lub Service. Co ważne, ogólnie mówiąc, imiona dokładnie przekazują to, co jest modelowane. I to jest sedno problemu: "Usługi" lub "Menedżerowie" nie są rzeczywistymi obiektami, które próbujemy modelować w naszych obiektach oprogramowania. Są raczej miejscami, w których zbieramy mnóstwo metod, które robią rzeczy, które po prostu nie pasują do obowiązków któregokolwiek z obiektów, które potrzebujemy/chcemy wymodelować.

Osobiście preferuję "usługę", ale tylko dlatego, że "menedżer" wydaje się być czymś, co można faktycznie modelować, tzn. Mogą istnieć menedżerowie w świecie rzeczywistym, którzy reprezentują nasze obiekty "menedżerskie". Ale kwestia jest całkowicie akademicka i natychmiast przyznaję, że nie ma żadnej praktycznej różnicy.

To, co naprawdę ważne, jest zazwyczaj o wiele bardziej podstawowe niż takie delikatne punkty: mieć model dobrze zrozumiały dla wszystkich zaangażowanych w rozwój. Jeśli moje doświadczenie ma cokolwiek do zrobienia, rzadko tak jest. Moja wskazówka dla tych, którzy pytają, czy "menedżer" lub "służba" jest właściwą metaforą, to: Odwróć monetę, upewnij się, że wszyscy wiedzą o konwencji, i spędź swój czas rozważając i omawiając ważne sprawy!

Answer 7

Dla mnie klasa usług dotyczy implementacji przypadku użycia, więc nazywam ją zgodnie z tym, jakiego rodzaju użytkownika działa usługa w imieniu. Jeśli więc mam aplikację o różnych rolach, np. Klienci, ludzie odpowiedzialni za porządek, osoby wprowadzające dane i administratorzy, to prawdopodobnie skorzystam z usługi CustomerService, usługi OrderFulfillment, usługi DataEntry i usługi administracyjnej. Wydaje mi się, że nazewnictwo usługi w zależności od rodzaju pobieranych lub przekręcanych danych to anty-wzorzec. Zgadując, że manipulacja UserAccount byłaby domeną administratora, prawdopodobnie nazwałbym to "AdminService".

Answer 8

Zakładając, że są to usługi REST, myślę, że twoja konwencja nazewnictwa URI jest ważniejsza niż nazwa podstawowych usług wdrożeniowych, ponieważ ta ostatnia będzie w dużej mierze niewidoczna dla klientów. Oczywiście chcesz konsekwentnie nazwać wewnętrznie, ale nie jest to tak ważne.

Niektóre wytyczne REST użyliśmy: http://soaprobe.blogspot.co.uk/2012/10/soa-rest-service-naming-guideline.html (mój blog)

Answer 9

związane z różnicą między menedżerami i usług: powiedziałbym stosowanie jednej warstwy logiki biznesowej (warstwa usługa lub warstwa Manager) tak długo, jak to możliwe.

Jak tylko że warstwa komplikuje (zakładamy użyłeś usługi) można dodać menedżerów z odpowiedzialności delegowanie do jednej usługi czy inny sposób, ale zachować logikę biznesową wewnątrz usługi.

Utrzymałbym więc usługi w prosty sposób, używałbym menedżerów do zarządzania usługami i utrzymywania logiki biznesowej wewnątrz usług.

Zgadzam się również z unikaniem sufiksu Impl dla implementacji i unikaniem sufiksu I dla interfejsów. Jako przykład, nazywanie interfejsu "Controller" i nazywanie implementacji "SimpleController" lub "UserController" brzmi dla mnie lepiej.