Spring Boot 2.0 - Proje Yapısı ve En İyi Uygulamalar (2. Bölüm)
Spring Boot v2.0 serisinin ilk bölümüne devam ederken, bu, Spring Boot tabanlı bir geliştirme yaparken göz önünde bulundurulması gereken bazı önemli snippet'ler ve en iyi uygulamalarla birlikte uygulama proje yapısını inceleyeceğimiz ikinci ve son kısımdır. .
Sadece küçük bir feragatname, bu başlangıç kitini kurduktan ve kapsamlı bir inceleme yaptıktan sonra, bunun Spring Boot kullanarak bir mikro servis uygulaması olmadığını hissedebilirsiniz, söylemem gerekir ki, bu tamamen seninle aynı fikirde değil. Spring Boot'de geliştirilen monolith. Bu makale Spring Boot’teki en iyi uygulamalarla kod yazmayı öğrenmekle ilgili ve ideal olarak bir rezervasyon sisteminin birden fazla servis veya kod tabanına sahip olması gerekiyor, söz veriyorum, yakında dağıtılmış bir uygulama oluşturmada Spring Boot’ın kullanımıyla ilgili yeni bir dizi yayınlayacağım söz veriyorum. Netflix OSS yığınının yardımıyla. O zamana kadar lütfen bunu bir başlangıç noktası olarak ele alın ve proje yapısını ve ilgili araçları aynı hizaya getirin.
Kaynak kodu
Bu başlangıç kitinin kaynak kodu aşağıdaki GitHub deposundan klonlanabilir:
Uygulama yapısı
Spring Boot, yaşamını çok kolaylaştıran, kendilerine Spring Spring'in dikkatini çeken Spring Framework versiyonuna dayanan farklı bağımlılıkların versiyonlarını seçmek zorunda olmadığımız için, düşünceyi düşündüren bir çerçevedir.
Proje yapısını oluştururken aynı ideolojiyi takip etmeye çalıştım, ilk başta çok zor gibi gözüküyor, ama parçalarınızı yazmaya başladığınızda bir kez bana yapıyı zamandan tasarruf ederek ve zaten cevaplanmış sorular hakkında düşünerek yardımcı olacağına inanıyorum. . Yapı aşağıdaki gibi görünüyor:
Modeller ve DTO'lar
Uygulamanın çeşitli modelleri, model paketi altında düzenlenir, DTO'ları (veri aktarım nesneleri) dto paketi altında bulunur. DTO'ları kullanıp kullanmamamız konusunda farklı görüşler var, DTO'ları kesinlikle kullanmamız gerektiğini ve kullanmamamız gerektiğini düşünen akıl setine aitim, model katmanınızı UI katmanıyla çok sıkı bir şekilde birleştiriyor ve bu hiçbir işletme projesinin hiç yapmaması gereken bir şey. içine girmek.
DTO'lar, birkaç alt nesne kullanarak topladığımız ve veritabanında ısrar ettiğimiz tüm model nesnesini değil, yalnızca kullanıcı arabirimiyle paylaşmamız gereken verileri aktarmamıza izin veriyor. Modellerin DTO'lara eşlenmesi ModelMapper yardımcı programı kullanılarak yapılabilir, ancak yalnızca DTO'nuz (tam anlamıyla) ilgili modellerle neredeyse aynı olduğunda (her zaman durum böyle olmayan ve dolayısıyla özel haritalayıcı sınıfları kullanmayı tercih ediyorum) kullanışlıdır. Bazı örnekleri “dto / mapper” paketi altında bulabilirsiniz.
Örneğin, Trip.java modelimizin nasıl organize edildiğine bir bakalım:
Trip.java
Gördüğümüz gibi model, Durak, Otobüs ve Ajans koleksiyonlarına atıfta bulunuyor. Bu, çeşitli koleksiyonlar arasındaki ilişkiyi bir Trip ile sürdürmek için gereklidir. Bu, MySQL'deki bir yabancı anahtar kavramı ile aynı olmasa da, burada uygulanan varsayılan basamaklama yokken, aynı şeyi MongoDB'de taklit etmenin bir yolunu veriyor. İlgili veri transfer nesnesi aşağıdaki gibi görünür:
TripDto.java
Daha önce de açıkladığım gibi, DTO'lar, model meslektaşlarının ayna görüntüsü anlamına gelmez, bunun yerine kullanıcı arayüzünün veya api yanıtının ne istediğinin bir yansıması olmalıdır. Bu durumda, Yolculuk ile Otobüs veya Ajansı ya da Durakları arasında bir kompozisyon ilişkisi kurmanın bir anlamı yoktu, bunun yerine birincil anahtarları gerçekten hile yapabilir. Bu yalnızca bu DTO'ları ayırmakla kalmaz, aynı zamanda sunucudan istemciye HTTP üzerinden seyahat edecek yanıt paketinin toplam boyutunu da azaltır.
Bir sonraki soru POJO modelini bu DTO'ya nasıl dönüştürebileceği olabilir, peki bunu yapmanın birden fazla yolu vardır, ancak tercihim açık ve DIY olmaktır:
Hizmetler ve DAO'lar
Veri erişim nesneleri (DAO'lar) depo paketinde bulunur. Bunların hepsi, MongoDB'den verileri almaya ve almaya devam etmek için servis katmanına yardımcı olan MongoRosostatory arabiriminin uzantılarıdır.
Servis katmanı, iki temel hizmet yaratmanın mantıklı olduğu durum çalışması dikkate alınarak servis paketi altında tanımlanmıştır:
- Kullanıcı Hizmeti ve
- BusReservationService
Bu hizmetlerdeki her bir yöntemi açıklamak bu blog gönderisinin kapsamı dışındadır, ancak bu hizmetler tarafından desteklenen işlemleri gösteren arabirimleri listeleyeceğim.
UserService.java
BusReservationService.java
Metot adlandırma kurallarını fark etmenin yanı sıra, servis katmanının hiçbir zaman girdi olarak bir modeli kabul etmediğini ve asla birisini asla geri almadığını fark ettiğinizden eminim. Bu, Spring geliştiricilerinin katmanlı bir mimaride izlemesi gereken bir başka en iyi uygulamadır. Denetleyici katmanı, görünümden veya api katmanından bir istek aldığında bir işi yapmak için servis katmanıyla etkileşime girer, bunu yaparken model nesnelerine erişimi olmamalıdır ve her zaman nötr DTO'lar cinsinden konuşmalıdır.
Servis bir DTO nesnesi aldığında, karşılık gelen model nesnesini veritabanından sorgulayarak anlamlandırmaya çalışmalı ve ardından gerekli işlemi yapmalı ve geri arama servisine geri gönderilmek üzere bir DTO yanıtı yaratmalıdır. Bu yaklaşım, birinin diğerini kırabileceğinden endişe etmeden görünümü ve modelleri bağımsız olarak değiştirmenize olanak sağlar.
Yukarıda bahsedilen yaklaşımı göstermek için, kullanıcının bilgilerini güncellemek için kullanılan bir hizmet işlemi “updateProfile” örneğini ele alalım. Yöntem tanımı aşağıdaki gibidir:
Güvenlik
Güvenlik ayarı yapılandırma paketi altında bulunur ve gerçek yapılandırmalar güvenlik paketi içinde mevcut olan sınıf altında yapılır. Uygulama yönetici portalı ve REST API'leri için farklı güvenlik konseptlerine sahiptir, portal için oturum kimliği ve çerezler kavramına dayanan varsayılan ilkbahar oturum mekanizmasını uyguladım. REST API'leri için JWT token tabanlı kimlik doğrulama mekanizması kullandım.
Web ve apis güvenliği, MultiHttpSecurityConfig.java sınıfında aynı sınıfta yapılandırılmıştır. Gelen istekler için http güvenliğini yapılandırabilmemiz için WebSecurityConfigurerAdapter'tan uzanan iki statik sınıfa sahiptir.
@Order ek açıklaması, isteklerin belirtilen sırada farklı yapılandırmalar aracılığıyla taranmasına izin verir. Bu yüzden bir API isteği ApiWebSecurityConfigurationAdapter'dan geçer ve orada emilir, ancak bir Yönetici isteği ilk önce bu işlemi uygular ancak Spring Security'nin bu durumda bir sonraki yapılandırmadan hemen daha yüksek bir sırayla geçmesini sağlamaya çalıştığı kriterlere uymadığından FormLoginWebSecurityConfigurerAdapter nedir.
API istekleri, giriş sırasında verilen JWT tokeninin oluşturulmasından ve doğrulanmasından sorumlu olan ApiJWTAuthenticationFilter ve ApiJWTAuthorizationFilter'den geçmelidir. API kimlik doğrulaması için hangi URL'nin kullanılması gerektiğini merak ediyorsanız (giriş), burada:
http: // localhost: 8080 / API / auth
Bunun nasıl yapılandırıldığını merak ediyorsanız, cevap ApiJWTAuthenticationFilter sınıfındadır, yapıcısı kodlanmış aşağıdaki bilgilere sahiptir:
this.setRequiresAuthenticationRequestMatcher (yeni AntPathRequestMatcher ("/ api / auth", "POST"));
Bu, AbstractAuthenticationProcessingFilter'a, AuthenticationRequestMatcher'a API istekleri için “/ api / auth” yolunu bağlamasını söyler.
Yönetici uygulamasına yalnızca rolü “ADMIN” olan kullanıcılar için izin verilir. Tüm şifreler BCryptPasswordEncoder kullanılarak şifrelenir ve veritabanına kaydedildikten sonra gerçek değerlerini asla göremeyiz.
Kontrolörler
Son olarak, fakat en önemli kısım denetleyici katmanıdır. Bir isteğin ele geçirildiği andan yanıt hazırlanana ve geri gönderilene kadar her şeyi bir araya getirir. Denetleyici katmanı denetleyici paketinde bulunur, en iyi uygulamalar bu katmanı uygulamanın birden çok sürümünü desteklemek için sürümde tutmamızı önerir ve aynı uygulama burada uygulanır.
Şimdilik kod sadece v1'de var ancak zaman içerisinde farklı özelliklere sahip farklı sürümleri olmasını bekliyorum. Yönetici portalı ile ilgili denetleyiciler kullanıcı arabirimi paketinde bulunur ve ilgili form komut nesneleri komut paketinin altında bulunur. REST API denetleyicileri api paketinin altında bulunur ve karşılık gelen istek sınıfları istek paketinin altında bulunur.
Yönetici paneli denetleyicileri, Bahar WebMVC konsepti üzerinde çalışır. İlgili web isteklerine, Spring’in ModelAndView nesnesiyle ilgili görünümlerde / formlarda gösterilecek verileri içeren ve oluşturulacak görünümün adı olan DashboardController sınıfından bir örnekle yanıt verdikleri gibi:
İstek ve Form Komutları
Yine, geliştirici topluluğu arasında, gelen talebi haritalamak için ayrı sınıfların kullanımıyla ilgili DTO'ların kullanılmasıyla doğrudan modellerin kullanılmasıyla ilgili farklı görüşler var. Şahsen ben UI arasında gevşek eşleşmeyi teşvik etmek için onları olabildiğince ayırma hayranıyım. denetleyici katmanı.
İstek nesneleri ve form komutları, kalıcılık ve veri alımı için geçerli bilgileri servis katmanına aktaran DTO'lara dönüştürülmeden önce gelen isteklere ek bir doğrulama düzeyi uygulama yolu sunar. Burada DTO'ları kullanabiliriz ve bazı geliştiriciler bazı ek sınıfları azalttığı için bu yaklaşımı tercih ederler, ancak ben genellikle doğrulama mantığını aktarma nesnelerinden ayrı tutmayı tercih ederim ve dolayısıyla istek / komut nesnelerini önlerinde kullanma eğilimindeyim.
BusFormCommand sınıfına dayalı örnek bir komut deseni aşağıdaki gibidir:
API aracılığıyla gönderilen bir talebe örnek olarak BookTicketRequest aşağıdaki gibidir:
Statik kaynaklar, kaynaklar dizini altında gruplandırılmıştır. Tüm UI nesneleri ve şekillendirme özellikleri burada bulunabilir.
Lombok
Java'ya karşı en büyük şikayetlerden biri, tek bir sınıfta ne kadar gürültü bulunabileceğidir. Lombok Projesi bunu bir sorun olarak gördü ve en kötü suçlulardan bazılarının gürültüsünü basit bir açıklama dizisiyle değiştirerek azaltmayı amaçlıyor. Lombok'un bu başlangıç kitinde her yerde çalıştığını göreceksiniz, aslında kod satırlarının azaltılmasında, geliştirme zamanından ve çabadan tasarruf etmede ve kodu daha okunaklı hale getirmede yardımcı oldu. Kullanmayı tercih ettiğim en önemli ek notlardan bazıları:
@ Alıcı / @ Setter
Genel int intF getFoo () {return foo;} bir daha asla yazmayın.
@ToString
Alanlarınızı görmek için bir hata ayıklayıcı başlatmanıza gerek yok: Sadece lombok'un sizin için bir toString üretmesine izin verin!
@EqualsAndHashCode
Eşitlik kolaylaştırıldı: hashCode oluşturur ve nesnenizin alanlarından uygulamaları eşittir ..
@Veri
Şimdi hep birlikte: @ToString, @EqualsAndHashCode, tüm alanlardaki @Getter ve tüm son olmayan alanlardaki @Setter için bir kısayol ve
@RequiredArgsConstructor!
Özünde, aşağıdaki gibi ayrıntılı bir şey:
Basitçe şöyle yazılabilir:
Aradaki farkı çok daha iyi görebilirsiniz, sadece daha sonradan daha temiz görünmekle kalmıyor, 59 satır sıkıcı POJO'dan 8 satır tabanlı bir java sınıf dosyasına düştük.
API Yanıtı ve İstisna İşleme
RuntimeExceptions ile biraz denemeye çalıştım ve uygulamanın istisnalarının tümünü birkaç sınıf ve özellik dosyası kullanarak ele almak için küçük bir çerçeve buldum. İstisna paketini dikkatlice gözlemlerseniz, iki numaradan oluşur:
- Varlık Türü ve
- ExceptionType
EntityType enum, sistemde kalıcılık için kullandığımız ve bir çalışma zamanı istisnasına yol açabilecek tüm varlık adlarını içerir. ExceptionType enum, EntityNotFound ve DuplicateEntity istisnaları gibi farklı varlık seviyesi istisnalarından oluşur.
BRSException sınıfı, servis katmanından en çok atılan iki istisna olan EntityNotFoundException ve DuplicateEntityException statik sınıflarına sahiptir. Ayrıca, EntityType, ExceptionType ve argümanlarını şablonunu custom.properties dosyası altında bulunan formatlanmış bir mesajla ortaya çıkaran bir dizi aşırı yüklenmiş metodlar throwException'ı içerir.
Bu sınıfı kullanarak, kod tabanını her türlü NOT_FOUND ve DUPLICATE varlık istisnası ile karıştırmadan, çeşitli varlık istisnalarını tek tip bir şekilde atmak için tüm hizmetler katmanını yetkilendirebildim.
Örneğin, giriş yaparken, kayıtlı olmayan bir e-posta adresini kullanmaya çalışırsanız, aşağıdaki tek kod satırı kullanılarak bir istisna oluşturulur ve atılır -
istisna atma (USER, ENTITY_NOT_FOUND, userDto.getEmail ());
Bu, bu iki enum öğesinin USER (“kullanıcı”) ve ENTITY_NOT_FOUND (“not.found”) adlarının toplanmasına ve custom.properties dosyalarında aşağıdaki gibi bir anahtar user.not.found ile sonuçlanmasına neden olur:
user.not.found = E-posta ile talep edilen kullanıcı - {0} mevcut değil.
Sadece {0} paragrafını atılan istisnada yer alan e-posta adresiyle değiştirerek, kullanıcıya gösterilmek veya REST API çağrısının cevabı olarak geri gönderilmek üzere iyi biçimlendirilmiş bir mesaj alabilirsiniz. BRSException sınıfının tanımı aşağıdaki gibidir:
Bu mini çerçevenin bir diğer önemli kısmı, aşağıdaki gibi görünen CustomizedResponseEntityExceptionHandler sınıfıdır:
Bu sınıf, API isteklerine bir yanıt göndermeden önce bu RuntimeExceptions işlemlerini gerçekleştirir. Hizmet katmanı çağırma işleminin bir EntityNotFoundException veya bir DuplicateEntityException ile sonuçlanıp sonuçlanmadığını denetleyen ve arayan kişiye uygun bir yanıt gönderen denetleyici tavsiyesidir.
Son olarak, API yanıtının tümü, dto / response paketinde bulunan Response sınıfını kullanarak düzgün bir şekilde gönderilir. Bu sınıf, aşağıda gösterildiği gibi bir cevapla sonuçlanan tek tip nesneler yaratmamıza izin verir (bu, “api / v1 / booking / stop” api için bir cevaptır):
{ “Durum”: “Tamam”, “Yük”: [ { “Kod”: “STPA”, “Name”: “Durdur A”, “Detail”: “Tepelerin yakınında” }, { “Kod”: “STPB”, “Ad”: “B Durdur”, “Detail”: “Nehir kenarında” } ] }
Bir istisna olduğunda (örneğin, herhangi bir veri yolu ile bağlantısı olmayan iki durak arasında bir yolculuk ararken) aşağıdaki yanıtlar geri gönderilir (“api / v1 / booking / tripsbystops” GET isteğinin sonucu):
{ “Durum”: “NOT_FOUND”, “Hatalar”: “Şu anda kaynak durdurma -‘ STPD ’ile hedef durdurma -‘ STPC ’arasında yolculuk yok.” }
{ “Durum”: “NOT_FOUND”, "hatalar": { “Zaman damgası”: “2019–03–13T07: 47: 10.990 + 0000”, “Message”: “Kodlu istenen durma - STPF mevcut değil.” } }
Görebildiğiniz gibi, her iki yanıt türünde, biri HTTP-200'lü ve diğeri HTTP-404'lü yanıt yükü yapısını değiştirmez ve çağrı çerçevesi, bir durum ve bir hata olduğunu bilerek yanıtı açıkça kabul edebilir veya JSON nesnesindeki yük alanı.
API Belgeleri
Çalışmanızı belgelemek (gelişimi gibi) ve Spring Boot API'lerinin ön uç ekipleri (dahili) veya harici tüketiciler için okunabilir bir şekilde hazır olduğundan emin olunması önemlidir. Bu başlangıç kitinde kullanılan API dokümantasyonu için kullanılan araç Swagger2'dir, aynı URL’yi bir tarayıcı içinde açabilirsiniz.
http: // localhost: 8080 / dayı-ui.html
Size iki özelliğe sahip, iyi yapılandırılmış bir UI sunacak:
1. Kullanıcı
2. BRS
Taşıyıcı belirteci oluşturmak için oturum açma API'sini yürütmek için Kullanıcı belirtimini kullanabilirsiniz. Belirteç daha sonra varsayılan olarak tüm güvenli apislere uygulanacak olan “Yetkilendir” açılır penceresine uygulanmalıdır (her ikisini de al ve gönder). Yetkilendirme iletişim kutusuna uygulamadan önce, “Taşıyıcı” kelimesini ve ardından tokenin önüne boşluk bırakmanız gerektiğini lütfen unutmayın.
Swagger'ın yapılandırması BrsConfiguration sınıfına göre halledilmektedir. “SwaggerBRSApi” ve “swaggerUserApi” yöntemleriyle orada iki özellik tanımladım. Oturum açma bölümü varsayılan olarak Spring Security tarafından halledilir olduğundan, sistemde tanımlanan apilerin geri kalanı olarak apisini açıkça gösteremiyoruz ve aynı sebepten dolayı, config paketinde bir denetleyiciyi ismiyle tanımladım. “FakeController”:
Amacı, oturum açma ve kapatma apisleri için swagger dokümantasyonunun oluşturulmasını kolaylaştırmaktır, “/ api / auth” api kod tabanında tanımlanmış güvenlik filtreleri tarafından işlendiğinden, uygulama ömrü boyunca asla ortaya çıkmayacaktır. Bazı şeyleri biraz daha iyi görmenize yardımcı olacak bazı örnek ekran görüntüleri:
Swagger Kullanıcı Arayüzünü kullanmak ve güvenli API'leri kullanmak için önce Kullanıcı özelliğinden “/ api / auth” yi çalıştırmanız ve bir Taşıyıcı jeton oluşturmanız gerekir. Belirteç yayınlandıktan sonra, güvenli API'leri yürütmek için Yetkilendir açılır penceresine kaydedebilir ve ardından BRS özelliğine geçebilirsiniz. Belirteci kaydetmediyseniz, HTTP 401 hatasını almaya devam edersiniz.
Parametreleri olan bir gövdeye sahip olan HTTP-GET istekleri için Swagger-Ui'yi denerken sorun yaşayabilirsiniz, endişelenmeyin, Swagger'ın GET ve DELETE istekleri için destek paragraflarını durdurmaya karar vermesi, kodun hatası değil . Geçici bir çözüm olarak, kıvrılma isteğini swagger'dan kopyalayabilir ve bir terminal penceresinin içinde yürütebilirsiniz; bu, iyi sonuç vermelidir veya Postman veya benzer bir aracı, bu kadar sıkı bir kısıtlama uygulamamaktadır. Benim görüşüme göre, Open API spesifikasyonları GET taleplerinde vücut paramlarını kısıtlamadığı sürece, Swagger gibi araçlar da yapmamalı, geliştirici olarak değil, yapmaları gereken bir çağrı.
UI Mimarisi
Yönetici portalı için kullanıcı arayüzü, Bootstrap ve duyarlı web uygulaması konsepti yardımıyla materyal tasarımı kullanılarak tasarlanmıştır. UI, Thymeleaf şablonları (Bahar'da tercih edilen şablonlama motoru) kullanılarak oluşturulan sunucu tarafıdır.
Thymeleaf ile çalışmanın standart yolu kullanmaktır. Bu, genellikle, bir web sitesinde çok sayıda sayfa bulunduğunda ve her sayfada birkaç yeniden kullanılabilir bileşen (örneğin üstbilgi, gezinme, kenar çubuğu ve altbilgi) olduğunda, tekrarlayan kodlara neden olur. Her içerik sayfasının aynı yerlerde aynı parçaları içermesi gerektiğinden yinelenir. Bu, sayfa düzeni değiştiğinde, örneğin kenar çubuğunu soldan sağa doğru yerleştirirken.
Thymeleaf Layout lehçesi tarafından kullanılan dekoratör deseni bu sorunları çözer. Şablon motorları bağlamında, dekoratör modeli artık içerik sayfalarında bulunanlarla çalışmaz ancak ortak bir şablon dosyasına atıfta bulunur. Her sayfa temelde yalnızca ana içeriği sağlar ve şablon motorunu kullanmak için hangi temel şablonu kullanabileceğini açıklayarak son sayfayı oluşturabilir. İçerik, şablon dosyası ile dekore edilmiştir. Bu yaklaşım, parçaları dahil etmenin standart yoluyla karşılaştırıldığında avantajlara sahiptir:
- Sayfanın yalnızca içeriği sağlaması gerekir.
- Bir şablon dosyası son sayfayı oluşturmak için kullanılırken, genel değişiklikler kolayca uygulanabilir.
- Kod kısalır ve daha temiz hale gelir.
- Her içerik sayfası hangi şablon dosyaya atıfta bulunduğundan, uygulamanın farklı alanları için (örneğin, genel alan ve yönetici alanı) farklı şablonlar kullanmak kolaydır.
Yönetici portalı düzeni aşağıdaki gibi tasarlanmıştır:
Bu düzendeki ayrı alanlar aşağıdaki amaca hizmet eder:
- Başlık: Bu parça statik ithalat (CSS ve JavaScript), başlık ve meta etiketleri için kullanılır.
- Gezinme: sağ üstte kullanıcı profili ile gezinti çubuğu.
- İçerik: istenen sayfa ile değiştirilecek içerik yer tutucusu.
- Kenar çubuğu: Ek bilgi için bir kenar çubuğu.
- Altbilgi: Telif hakkı bilgisini sağlayan altbilgi alanı.
Bu bileşenler kök dizinindeki kaynaklar / şablonlar dizininde ve alt dizin parçaları ve düzeninde bulunabilir. Bu düzendeki içerik alanı aşağıdaki sayfaları barındırır:
- Gösterge Paneli
- Ajans
- Otobüs
- gezi
- Profil
Ayrıca, işlenmeyen istisnalar için bir hata sayfası “error.html” adıyla tasarlanmıştır. Giriş ve kayıt sayfaları, giriş yapmış bir kullanıcı tarafından erişilebilen portaldan ayrı olarak tasarlanmıştır.
Sunucuyu Yerel Olarak Çalıştırma
Bu Spring Boot uygulamasını çalıştırabilmek için önce onu oluşturmanız gerekecek. Spring Boot uygulamasını derlemek ve Maven ile tek bir çalıştırılabilir Jar dosyasına paketlemek için, aşağıdaki komutu kullanın. Pom.xml dosyasını içeren proje klasöründen çalıştırmanız gerekecektir.
maven paketi
ya da kullanabilirsiniz
mvn temiz yükleme
Uygulamayı bir terminal penceresinden çalıştırmak için java-jar komutunu kullanabilirsiniz. Spring Boot uygulamanızın çalıştırılabilir bir jar dosyası olarak paketlenmesi sağlandı.
java -jar hedef / yayılma-başlangıç seti-0.0.1-SNAPSHOT.jar
Uygulamayı çalıştırmak için Maven eklentisini de kullanabilirsiniz. Spring Boot uygulamanızı Maven eklentisi ile çalıştırmak için aşağıdaki örneği kullanın:
mvn spring-boot: çalıştırma
Yukarıdaki komutların herhangi birini / tümünü izleyebilir veya en sevdiğiniz IDE'niz tarafından sağlanan çalıştırma yapılandırmasını kullanabilir ve geliştirme amaçları için uygulamayı buradan çalıştırıp hata ayıklayabilirsiniz. Sunucu kurulduktan sonra, aşağıdaki arayüzden yönetici arayüzüne erişebilmelisiniz:
http: // localhost: 8080
Ve REST API'lerine aşağıdaki temel yoldan erişilebilir:
http: // localhost: 8080 / API /
Önemli api bitiş noktalarından bazıları şunlardır:
- http: // localhost: 8080 / api / v1 / kullanıcı / kayıt (HTTP: POST)
- http: // localhost: 8080 / api / auth (HTTP: POST)
- http: // localhost: 8080 / api / v1 / booking / stoplar (HTTP: GET)
- http: // localhost: 8080 / api / v1 / booking / tripsbystops (HTTP: GET)
- http: // localhost: 8080 / api / v1 / booking / tripschedules (HTTP: GET)
- http: // localhost: 8080 / api / v1 / booking / bookticket (HTTP: POST)
Docker Kabı
Konteyner görüntüsünü oluşturmak için lütfen aşağıdaki komutu kullanın:
liman işçisi -t bahar / başlangıç seti.
Ve kabı çalıştırmak için aşağıdaki komutu kullanın:
liman işçisi -p 8080: 8080 ilkbahar / başlangıç seti
Konteyner görüntüsünü oluştururken ve mongodb sisteminizde yerel olarak çalışıyorsa, bağlanabilmek için sisteminizin IP adresini (veya bulutta barındırılan veritabanının IP'sini) application.properties dosyasına (veya env vars) vermeniz gerekir. Veri tabanına konteynerin içinden.
Sonuç
Gördüğünüz gibi başlangıç kiti, size kendi gelişiminizi temel alabilmeniz için düzenli, verimli ve temiz kodlanmış bir arayüz ve mimari sağlayarak saatlerce kodlama süresinden tasarruf etmenizi sağlayacak şekilde tasarlanmıştır. Deneyin ve görüşlerinizi bildirdiğinizden emin olun.
İnşallah bu iki makale dizisi Spring Boot beceri setinizi geliştirmenize yardımcı olmuş ve bir sonraki Spring Boot uygulamanızı yazmaya başlamanız için size sağlam bir platform sağlamıştır.
Herkese kodlama mutlu!
Sizin için ilginç veya yararlı olduysa, lütfen alkış düğmesine basın ve başkalarının da bu hikayeyi bulmasına yardımcı olun.
50 alkış alabileceğini biliyor muydun?