Konwencja nazewnictwa dla kontekstu aplikacji Spring XML

Question

Decyduję się na konwencję nazewnictwa dla moich plików kontekstowych aplikacji Spring. Natknąłem się na to blog i kilka samouczków sugerujących applicationContext-<name>.xml jest drogą do zrobienia. Generalnie nie jest to przypadek mieszania wielbłąda z myślnikami/podkreśleniami. Jakie widzieliście już inne konwencje nazewnictwa?

Edycja: Myślę również o zagnieżdżaniu plików kontekstowych wewnątrz pakietu, który ich dotyczy. Na przykład moje klasy/interfejsy, które odnoszą się do zamawiania, zostaną umieszczone w pliku kontekstowym com/mycompany/order/spring-context.xml. Chciałbym mieć najwyższy poziom applicationContext.xml, który ściąga wszystko razem. Propozycje?

Answer 1

Gdyby nie było to konwencja, chciałbym go mieć:

1. plików przechowywanych w opakowaniach (nie w domyślnym zestawie) aby wyeliminować potencjalne konflikty nazewnictwa i oznacza również, że nie muszą zawierać aplikację nazwa w nich, jest określona przez pakiet.
2. plików o nazwach wszystkie małe litery ze znakiem „-” do oddzielenia nazwy

staram poprzedzający moje wiosenne pliki konfiguracyjne z „wiosnę” sprawia, że ​​bardziej oczywiste, co one służą, ale nie jest to konieczne obowiązkowy.

Ale pozwól mi powiedzieć, że zadziała to w sposób, w jaki radziłem sobie z moimi plikami źródłowymi, może nie działać we wszystkich kontekstach.

IMHO applicationContext- <nazwa> .xml jest trochę verbose (długa) i lubię wszystkie małe litery, ponieważ odróżnia je od mojego źródła java i (myślę) ułatwia ich czytanie.

Answer 2

Dla Web projektu MVC, staram się przełamać różne pliki kontekstowe wzdłuż linii odpowiedzialności:

• appname-dao.xml
• appname-servlet.xml
• appname-services.xml
• appname-security.xml

Answer 3

Albo wielbłąda lub separator "-" działałby na płetwę e, o ile jesteś konsekwentny. Wiem, że w naszym przypadku nie umieszczamy plików kontekstowych w tym samym katalogu co kod, chyba że sam kod jest Wiosenny, co w naszym przypadku nie jest.

Mamy dwa przypadki, w których używamy maven 2, plik kontekstu znajduje się w katalogu źródłowym/źródłowym, gdzie zasób jest rodzajem katalogu źródłowego java. Tam, gdzie używa się maven 1, po prostu tworzymy pakiet źródłowy i umieszczamy tam kontekst. Oba te przypadki zakładają "normalny" kod Java. W przypadku pakietów Wars, EJB i OSGi pliki zazwyczaj znajdują się w katalogu meta-inf.

Ponadto, nie używamy kontekstu aplikacji najwyższego poziomu do "ciągnięcia" wszystkiego razem. Po prostu tworzymy kontekst z wieloma plikami kontekstowymi. Jest to znacznie prostsze do testowania na różne sposoby, testy jednostkowe z próbnymi obiektami, testy integracyjne bez serwera i pełne testy integracyjne wdrożone na serwerze. We wszystkich tych scenariuszach po prostu przekonfiguruj sposób tworzenia kontekstu zamiast kontekstu "głównego" dla każdego scenariusza.

Answer 4

Bardzo popieram konwencję applicationContext-<name>.xml.

Ogólnie rzecz biorąc <name> odnosi się do nazwy modułu Maven we wszystkich naszych projektach. Zatem każdy moduł, który wymaga konfiguracji Spring, ma swój własny plik applicationContext-<name>.xml. "Moduł wykonawczy", tj. Jeden moduł, który reprezentuje rodzaj punktu wejścia do aplikacji (WAR, EAR, itp.), Ma pojedynczy applicationContext.xml, który tylko importuje wszystkie pliki applicationContext-<name>.xml.

Używamy tej konwencji w całej firmie ściśle we wszystkich naszych projektach Maven/Spring i okazało się to niezwykle proste, jasne i wydajne.