<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"><channel><title>نوشته های mirbozorgi.com</title><link>https://virgool.ir/feed/@mirbozorgi.com</link><description>ما تیم mirbozorgi.com هستیم. اگر بعد از خوندن مقاله های ما فکر کردید جایی در اشتباه هستیم؛ لطفا بما ایمیل بزنید. اگر هم نیاز به یادگیری تکنولوژی جدیدی دارید خوشحال میشیم بهتون کمک کنیم.</description><language>fa</language><pubDate>2026-11-10 19:20:18</pubDate><image><url>https://files.virgool.ir/upload/users/1027081/avatar/XBb6Fj.png</url><title>mirbozorgi.com</title><link>https://virgool.ir/@mirbozorgi.com</link></image><item><title>الگوهای طراحی (Design Patterns) رایج و کاربردی در فریم‌ورک spring (قسمت دوم)</title><link>https://virgool.ir/@mirbozorgi.com/الگوهای-طراحی-design-patterns-رایج-و-کاربردی-در-فریم-ورک-spring-قسمت-دوم-fc5ebe72ae4i</link><description>الگوی پروکسی (proxy)الگوی پروکسی یکی دیگر از الگوهای طراحی به شمار می رود. پروکسی‌ها ابزار‌های بسیار کاربردی و مفیدی در دنیای دیجیتال هستند و اغلب ما از آنها به صورت خارج از نرم افزار (مانند پروکسی‌های شبکه‌ای) استفاده می‌کنیم. در دنیای کد ها، الگوی پروکسی، تکنیکی است که به یک object (proxy) اجازه می‌دهد تا دسترسی به object دیگر، موضوع (subject) و یا سرویس را کنترل کند.تراکنش ها (Transactions)برای ایجاد یک پروکسی، ما ابتدا یک object ایجاد می‌کنیم که رابط کاربری مشابهی با موضوع (subject) ما را implement می‌کند و حاوی ارجاع به subject است. سپس می توانیم از پروکسی به جای subject استفاده کنیم.در فریم‌ورک spring، bean‌ها برای کنترل دسترسی به bean زیرین proxied می‌شوند. ما این رویکرد را هنگام استفاده از transaction‌ها مشاهده می‌کنیم:در کلاس BookManager ما، متد ایجاد شده را با حاشیه‌نویسی (annotation) @Transactional، حاشیه‌نویسی (annotate) می‌کنیم. این حاشیه نویسی (annotation) به Spring دستور می‌دهد تا متد ایجاد (create method) ما را به صورت اتمی (atomically) اجرا کند. بدون وجود پروکسی، Spring نمی‌تواند دسترسی به bean BookRepository ما را کنترل کند و از ثبات تراکنش‌های آن اطمینان حاصل کند.پروکسی های CGLibدر عوض، Spring یک پروکسی ایجاد می‌کند که bean BookRepository ما را wrap می‌کند و bean ما را به صورت اتمی (atomically) برای اجرای متد create ما ابزار‌سازی می‌کند.وقتی ما متد BookManager#create خود را فرا می‌خوانیم، می‌توانیم خروجی (output) را ببینیم:به طور معمول، ما انتظار داریم که یک شناسه object استاندارد BookRepository را ببینیم، ولی در عوض، یک شناسه object EnhancerBySpringCGLIB را می‌بینیم.در پشت صحنه، spring، object BookRepository ما را به عنوان object  EnhancerBySpringCGLIB در داخل wrap کرده است. بنابراین Spring دسترسی به object BookRepository ما را کنترل می‌کند (اطمینان از سازگاری تراکنش ها یا transactional consistency).به طور کلی، Spring از دو نوع پروکسی استفاده می‌کند:پروکسی‌های CGLib - هنگام پروکسی سازی کلاس ها استفاده می‌شودJDK Dynamic Proxies – هنگام پروکسی سازی رابط‌ها (interface) استفاده می‌شوددر حالی که ما از تراکنش‌ها (transaction) برای افشای پروکسی‌های زیربنایی استفاده می‌کنیم، Spring برای هر سناریویی که در آن باید دسترسی به یک bean را کنترل کند، از پروکسی‌ها استفاده می‌کند.الگوی templateدر بسیاری از فریم‌ورک ها، بخش قابل توجهی از کدها را کد‌های boilerplate تشکیل می‌دهند.به عنوان مثال، هنگام اجرای یک پرس و جو (query) در پایگاه داده، همان سری از مراحل باید طی شوند:برقراری یک ارتباطاجرای queryاجرای تمیزسازی (cleanup)اتمام ارتباطاین مراحل یک سناریوی ایده آل برای اجرای الگوی template هستند.Template‌ها و callback‌هاالگوی template، به عنوان یکی از الگوهای طراحی، تکنیکی است که وظیفه‌ی تعریف مراحل مورد نیاز برای انجام برخی از اقدامات را بر عهده دارد؛ همچنین این الگو مراحل boilerplate را اجرا می‌کند و مراحل قابل تنظیم (customizable steps) را به صورت انتزاعی قرار می‌دهد. سپس کلاس‌های فرعی (Subclasses) می‌توانند این کلاس انتزاعی را پیاده‌سازی کنند و یک پیاده‌سازی مشخص (concrete implementation) را برای مراحل از دست رفته ارائه کنند.ما می توانیم به این صورت در مورد query پایگاه داده خود، یک template ایجاد کنیم:از طرفی دیگر، ما می‌توانیم مرحله‌ی گمشده (missing step) را با ارائه یک متد callback ارائه کنیم.روش callback روشی است که به subject اجازه می‌دهد تا به مشتری (client) سیگنال دهد که برخی از اقدامات مورد نظر انجام شده است.در برخی موارد، subject می‌تواند از این callback برای انجام اقداماتی استفاده کند (مانند نتایج نقشه‌برداری (mapping)).به عنوان مثال، به جای داشتن یک متد executeQuery، می توانیم به متد execute یک رشته‌ی query و یک متد callback برای رسیدگی به نتایج ارائه کنیم.ابتدا، ما متد callback را ایجاد می‌کنیم که یک object Results را می‌گیرد و آن را به یک object از نوع T، map می‌کند:سپس کلاس DatabaseQuery خود را برای استفاده از این callback تغییر می‌دهیم:این مکانیسم callback دقیقاً رویکردی است که فریم‌ورک Spring با کلاس JdbcTemplate از آن استفاده می‌کند.الگوی template Jdbcکلاس JdbcTemplate متد query را ارائه می‌دهد که یک query String و object ResultSetExtractor را پذیرش می‌کند:مواردی همچون ResultSetExtractor، object ResultSet را (که نشان دهنده‌ی نتیجه query است) به یک object دامنه (domain object) از نوع T تبدیل می‌کند:در ادامه، کد boilerplate را با ایجاد واسط‌های callback خاص‌تری کاهش می‌دهد.به عنوان مثال، رابط RowMapper برای تبدیل یک ردیف از داده‌های SQL به یک object دامنه از نوع T استفاده می‌شود.برای تطبیق رابط RowMapper با ResultSetExtractor مورد انتظار، Spring کلاس RowMapperResultSetExtractor را ایجاد می‌کند:به جای ارائه منطق (logic) برای تبدیل کل یک object ResultSet، از جمله تکرار در ردیف‌ها، می‌توانیم منطق نحوه‌ی تبدیل یک سطر را ارائه کنیم:با این مبدل، می‌توانیم با استفاده از JdbcTemplate، یک پایگاه داده (database) را query کنیم و هر ردیف حاصل را map کنیم:جدا از پایگاه داده JDBC، Spring همچنین از template‌ها برای موارد زیر نیز استفاده می‌کند:Java Message Service  (JMS)Java Persistence API (JPA)Hibernate (اکنون منسوخ شده)Transactionsسخن آخردر صورتی‌که انتقاد و یا پیشنهادی دارید، در قسمت نظرات ما را مطلع نمایید. همچنین می‌توانید برای دسترسی به کدهای بیشتر از سایت ما دیدن کنید.</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Fri, 12 Nov 2021 20:43:47 +0330</pubDate></item><item><title>آموزش آپاچی کافکا</title><link>https://virgool.ir/@mirbozorgi.com/آموزش-آپاچی-کافکا-cl4h6wwp6t8h</link><description>من اشکان کیمیا قلم از گروه میربزرگی هستم و در این مقاله به نکاتی در مورد آپاچی کافکا اشاره میکنیم :آپاچی کافکا چیست ؟آپاچی کافکا یک پلتفرم متن باز stream processing می باشد که جهت بررسی داده ها استفاده می شود و به عنوان یک واسط بین طرفین عمل می کند.منظور از طرفین  در جمله بالا تولید کننده ها( Producers) ومصرف کننده ها ( Consumers)می باشد .یک سیستم publish-subscribe messaging است که اجازه ی تبادل داده بین سرور ها ، نرم افزار ها و پردازنده ها را فراهم میکند .آپاچی کافکا در اصل توسط شرکت لینکدین توسعه داده شده است اما بعد ها شرکت آپاچی آن را خرید .هر موقع صحبت از آپاچی کافکا می شود همه ذهنشون به سمت ربیت ام کیو (RabbitMQ) هم می رود . در اینجا میتوانید مقدمه ای در مورد جفتشون بخونید .Messaging System چیست ؟سیستمی است جهت تبادل ساده پیام مابین دو یا حتی بیشتر از دو شخص یا دستگاه یا...که این پیام میتواند ریکوست باشد یا یک کویری در دیتابیس یا هر چیزی که فکر کنید..در این سیستم فرستنده پیام را به عنوان تولید کننده (Producer) و دریافت کننده ی پیام را به عنوان مصرف کننده (Consumer) میشناسیم .What is Streaming process(پردازش استریم چیست)به پردازش داده در سیستم های موازی پردازش استریم میگوییم .این پردازش اجازه می دهد که نرم افزار های مختلف اجرای موازی داده‌ها را انجام دهند .تعدادی از قابلیت های پردازش موازی در کافکا :-به محض اینکه استریم رکوردها اتفاق میوفتد پردازش شروع می شود .-به روشی کم خطا استریم های داده را ذخیره میکند .برای درک و لمس کامل کافکا باید 4 ای پی آی زیر را کامل بشناسید :Producer API:به نرم افزار اجازه میدهد استریمی از رکورد ها را منتشر (Publish ) .Consumer API:به نرم افزار اجازه می دهد که استریم های مختلف را دریافت و آن ها را پردازش کند .Streams API: این ای پی آی به نرم افزار اجازه می دهد که به شکل موثر استریم ورودی را به خروجی تبدیل کند .Connector API: اجازه ی اجرای ای پی آی های توسعه یافته توسط تولید کننده و دریافت کننده ها را فراهم میکندچرا از کافکا باید استفاده کنیم ؟1-قادر به مدیریت میلیون ها داده می باشد.2-به عنوان یک واسط میان مقصد و مبدا عمل میکند . و ارسال کننده باید داده را به کافکا و دریافت کننده باید از آن دریافت کند .3-بسیار کارایی بالایی دارد و با تاخیر کمتر از 10 میلی ثانیه بسیار عالی عمل میکند .4-اشتراک گذاری داده را بسیار راحت کرده است .5-شرکت های بزرگ دنیا نظیر نتفیلیکس ، اوبر ، والمارت از این سرویس استفاده میکنند .6-کافکا اجازه می دهد که سیستم در مواقعی که اروری دارد به کار خود ادامه دهد (fault-tolerance).به عنوان مثال در مواقعی که یک (Consumer)  پیام را موفقیت آمیز دریافت میکند اما به هر دلیلی نمیتواند پردازش کند امکان دوباره دریافت (Consume) آن پیام وجود ندارد . اما کافکا در همچین شرایطی با پردازش دوباره داده مشکل را حل میکند .</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Mon, 01 Nov 2021 21:02:31 +0330</pubDate></item><item><title>استفاده از میکروسرویس ها را متوقف و از مونولیت استفاده کنید</title><link>https://virgool.ir/@mirbozorgi.com/استفاده-از-میکروسرویس-ها-را-متوقف-و-از-مونولیت-استفاده-کنید-imbk09qzfcq9</link><description>من اشکان کیمیا قلم از گروه میربزرگی هستم و در این مقاله استفاده از معماری مونولیت به جای میکروسرویس و مزایا و معایب استفاده از میکروسرویس توسط شرکت ها را بررسی میکنیم :در نگاه اول همه جذب سرعت توسعه بالا و امکان پیاده سازی جداگانه بخش های مختلف با استفاده از میکروسرویس می شوند اما یکسری نکات وجود دارند که در پشت صحنه هزینه پروژه را برای شرکت ها افزایش میدهند .در زیر به تعدادی از آن ها میپردازیم : مدیریت داده آسون نیست !سینک نگه داشتن داده در میکروسرویس چالش برانگیر میشود. الگوی پیشنهادی در همچین شرایطی استفاده از دیتابیس های مختلف برای هر میکروسرویس می باشد .دلیل پیشنهاد این الگو کم شدن وابستگی تیم ها به یکدیگر وامکان کار کردن مجزا بدون اختلال می باشد .اما چه اتفاقی میوفته وقتی که 2میکروسرویسی که قرار بوده به صورت سینک کار کنند به مشکل بخورند ؟به عنوان مثال یکیشون دیتا رو آپدیت بکنه ولی اون یکی موفق نشه ؟ همچین نمونه ای باعث نا هماهنگی در دیتا می شود .پیدا کردن دیتای ناسازگار داخل سرویس ها کاری بسیار سخت و زمان بر است و علاوه بر این نیازمند کسی می باشد که تجربه کار داخل چند سرویس را داشته باشد.پس نتیجه میگیریم که در همچین شرایطی یکی از اصول اصلی میکروسرویس که جدا بودن هر سرویس و اختصاص داشتن هر سرویس به یک تیم می باشد را زیر پا گذاشته ایم .اما اگر از معماری مونولیت استفاده کرده بودیم میتوانستیم با قرار دادن جفت این اعمال با داده در داخل یک ترنزکشن درگیر حل کردن همچین مشکلی نشویم .زمان بیشتری باید صرف کنیدآماده سازی ویژگی های مختلف داخل معماری مونولیت در مقایسه با میکروسرویس زمان کمتری نیاز دارد . اگرچه که در یک سرویس به مشکل بر نمیخوریم ولی در مواردی که چندین سرویس داریم و باید با یکدیگر تعامل داشته باشند شرایط بسیار پیچیده تر از یک مونولیت میشود.در مونولیت میتوانیم با آماده سازی متد های عمومی کار را بسیار استاندارد و عمومی جلو ببریم ولی در میکروسرویس شما محکوم به صدا کردن متد های عمومی همان میکروسرویس هستید . در نتیجه علاوه بر همه ی کارها باید API یا Messaging System اختصاصی ارتباط بین سرویس ها را هم پیاده کنید .  میکروسرویس در تیم های بسیار بزرگ خیلی بهتر جواب میدهدلذت سپردن کار به تیم های مجزا در میکروسرویس را بیشتراز هر کسی شرکت های خیلی بزرگ لمس میکنند .البته که هر موقع حرف از میکروسرویس می شود همه به این ویژگی اشاره میکنند اما این واقعیت را در نظر نمیگیرند که شما نیازمند تعدادی نیرو برای هر میکروسرویس می باشید و باید زمان کافی داشته باشند که سرعت توسعه و خوانایی کد افزایش یابد .اکثر استارت آپ ها همچین پتانسیلی ندارند و در شروع کار که نیروی کافی وجود ندارد نیازمند نیروهایی می شوند که باید بر روی همه ی سرویس ها کار کنند که کار بسیار سختی است .دواپس پیچیده می شودیکی از دلایل خیلی مهم استفاده از میکروسرویس ها توانایی اجرای سرویس های مختلف بر روی سرور های مختلف می باشد .انتخاب زیر ساخت مناسب برای هر سرویس میتواند هزینه را به شکل زیادی کاهش دهد اما باید یه این نکته توجه کرد که پیاده سازی ، مانیتورینگ و کانفیگ کردن یک مونولیت اپلیکیشن در مقایسه با یک میکروسرویس کار بسیار آسون تری هستش .طبق تعاریف چون سرویس ها وابستگی کمی به یکدیگر دارند، امکان ادامه کار در صورت از کار افتادن سرویس های دیگر هم وجود دارد.اما تقریبا در موارد بسیار کمی ما شاهد وابستگی کم با وجود بزرگ شدن پروژه و زیاد بودن کاربران هستیم .هرچه تعداد بخش های معماری نرم افزار شما بیشتر شود امکان خطا داشتن هم بالاتر میرود.در پایان باید به این نکته اشاره کنیم که هدف از این مقاله بد جلوه دادن میکروسرویس نمی باشد . هدف اصلی،برآورد هزینه ی میکروسرویس برای یک شرکت ،نیاز به نیروی حرفه ای در طراحی میکروسرویس و عدم نیاز به میکروسرویس در هر پروژه ای است .اکثر شرکت ها با پیاده سازی مونولیت هزینه کمتری می کنند .زمان و انرژیتون رو در شروع استارت آپ صرف پیاده سازی میکروسرویس نکنید .در آخر اگر جایی نیاز به توضیح بیشتر بود حتماً به ما ایمیل بزنید و ما رو خوش حال کنید.سایت ما رو سر بزنید :‌https://mirbozorgi.com/</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Tue, 19 Oct 2021 17:53:33 +0330</pubDate></item><item><title>نحوه استفاده از CI/CD در Spring Boot</title><link>https://virgool.ir/@mirbozorgi.com/نحوه-استفاده-از-cicd-در-spring-boot-rankhkg0smeo</link><description>قطعاً پیش آمده که  در مورد CI/CD مطلبی خوانده و یا در repository گیت‌لب پروژه دیده باشید.در این مقاله قصد داریم مختصر توضیحاتی در خصوص این تکنولوژی ارائه دهیم.مفهوم CI (Continuous integration) :به فرآیند اتوماسیون که توسعه دهندگان برای ساخت، آزمایش و ادغام تغییرات کد برنامه استفاده می کنند.مفهوم CD (Continuous delivery) :پس ز اتمام مرحله‌ی قبل و انجام تست‌ها، در این بخش پروژه را در محیط‌های گوناگون به منظور نتیجه‌گیری deploy می‌کنند.نحوه استفاده :ابتدا از نصب بودن Gitlab Runner در پروژه خود اطمینان حاصل می‌کنیم.بدین منظور در صفحه‌ی پروژه به مسیر زیر رفته :Setting -&gt; CI/CD -&gt; Runner (Expand)و چک می‌کنیم که Runner وجود دارد و یا می‌بایست نصب کنیم.در صورتی‌که Runner نصب نباشد، با تصویر زیر مواجه می‌شویم :از این‌رو Runner مد نظر را از لینک‌ دانلود، دریافت نموده و نصب می‌کنیم.اجرا با Docker :پس از نصب و active شدن بخش قبل، نیاز داریم که یک فایل با نام زیر بسازیم:.gitlab-ci.ymlکه این فایل می‌بایست در پوشه اصلی پروژه قرار بگیرد.سپس دستورات مورد نیاز خود را در این فایل درج می‌کنیم.ما در این سند قصد داریم تا با این ابزار برنامه‌ی خود را توسط docker بالا بیاریم. همان‌طور که در تصویر مشاهده می‌کنید ابتدا image خود را docker:latest قرار دادیم، سپس سرویس آن را تعریف کردیم.یک stage به نام build ساخته و در بخش بعد توسط script این stage را پیاده‌سازی کردیم.اجرا و تست با Maven :در صورتی‌که قصد داشته‌باشیم پروژه خود را با maven بالا بیاوریم و تست‌های آن را انجام دهیم، می‌توانیم از کانفیگ زیر استفاده کنیم:پس از قرار دادن فایل مذکور در پروژه هرگاه که پروژه را به نسخه گیت آن push کنیم پروژه این مراحل جهت پاس شدن طی می‌کند.پس از push می‌توانید به در gitlab پروژه به بخش زیر رفته و نتیجه را مشاهده نمایید:CI/CD -&gt; Jobsهمان‌طور که در تصویر می‌بیند در صورت پاس شدن عبارت pass و در غیر این صورت عبارت failed را مشاهده می‌نمایید.مقامقاله jenkins هم میتونید از سایت بخونید.در صورتی‌که انتقاد و یا پیشنهادی دارید، در قسمت نظرات ما را مطلع نمایید. همچنین می‌توانید برای دسترسی به کدهای بیشتر از سایت ما دیدن کنید.</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Sat, 18 Sep 2021 00:35:44 +0430</pubDate></item><item><title>نمونه کد با الگوی Saga</title><link>https://virgool.ir/@mirbozorgi.com/نمونه-کد-با-الگوی-saga-swxsy0bdldhi</link><description>قصد داریم در این مقاله مختصر توضیحاتی در خصوص پیاده‌سازی یک پروژه ساده با بهره‌گیری از الگوی Saga را خدمت شما ارائه دهیم.معرفی پروژه :در این پروژه ما یک سرویس سفارش‌دهی داریم که روند آن بدین‌صورت است که کاربر محصولات را مشاهده نموده و سپس محصول مورد نظر خود را انتخاب می‌کند. پس از انتخاب به قسمت پرداخت هدایت شده و در صورتی‌که پرداخت موفقیت آمیز باشد، محصول مذکور برای کاربر ثبت می‌شود.تکنولوژی‌ها :Spring BootPostgreSQLRabbitMQمقدمه :قبل از شروع لازم می‌دانیم که مختصر توضیحاتی در خصوص نحوه‌ی پیاده‌سازی پروژه به شما بدیم.این پروژه به صورت Microservice نوشته شده و هر سرویس از معماری 3Tier layer بهره برده و سرویس‌ها برای ارتباط با یکدیگر از الگوی Saga و ابزار RabbitMQ استفاده می‌کنند.الگوی Saga چیست؟الگوی Saga یکی از 6 الگوی مهم مدیریت داده‌های Microservice است که می‌توان آن را نتیجه‌ی مستقیم الگوی Database-per-service دانست. در الگوی Database-per-service، هر Microservice مسئول داده‌های خود است. بااین‌حال سؤال اینجاست که چه اتفاقی می‌افتد اگر یک Transaction شامل داده‌هایی باشد که در چندین Microservice وجود دارد؟ در این موقعیت‌هاست که نیاز به الگوی Saga پدید می‌آید.الگوی Saga به‌عنوان الگوی معماری Microservice ها برای پیاده‌سازی Transaction هایی است که شامل چندین سرویس هستند. Saga توالی Microservice ها است. هر سرویس در یک Saga، Transaction خود را انجام داده و رویدادی را منتشر می‌کند. سایر سرویس‌ها به آن رویداد گوش می‌دهند و Transaction محلی بعدی را انجام می‌دهند. اگر به یک دلیل Transaction ای ناموفق باشد، این الگو، به‌منظور خنثی کردن تأثیر Transaction های قبلی، Transaction های  Compensating یا جبران کننده را اجرا می‌کند.ابزار RabbitMQ چیست ؟ابزار RabbitMQ، پیاده‌سازی یک واسط تبادل پیام است که اغلب به‌عنوان Service bus شناخته می‌شود. این ابزار از پیام‌های Classic که از Queue خارج می‌شوند پشتیبانی می‌کند. یک Developer Queue های نام‌گذاری شده ‌ای را تعریف می‌کند که Publisher ها می‌توانند پیام‌های خود را به آن‌ ها ارسال کنند. Consumer ها نیز از همان Queue ها برای برداشتن پیام به ‌منظور پردازش استفاده می‌کنند.حال می‌خواهیم توسط توضیحاتی که دادیم پروژه هدف را شرح دهیم:پروژه‌ی ما شامل ۴ بخش و ۳ سرویس زیر است :سرویس Order :همان‌طور که پیش‌تر توضیح دادیم ما در این پروژه از الگوی Saga و یا به زبان دیگر از event ها استفاده می‌کنیم. بدین صورت که در سرویس Order سه event با نام‌های زیر تعریف کردیم.OrderCanceledEventHandlerOrderDoneEventHandlerOrderEventListenerدر کلاس OrderService، پس از دریافت سفارش و ثبت آن، توسط تابع زیر سفارش ثبت شده را publish می‌کنیم.ما گفتیم که روند ثبت سفارش بدین صورت است که پس از ثبت در یک queue، سفارش publish می‌شود. ممکن است سوال پیش‌بیاید که در چه queueای و به چه صورت؟پاسخ در کلاس OrderEventListener است:به TransactionalEventListener Annotation توجه کنید. این ابزار به ما این امکان را می‌دهد که هنگامی که یک Transaction به صورت commit درآمد بر روی queue خواسته شده (که در این بخش با نام queue.order-create ثبت شده) یک مقداری را publish کند.سرویس Payment :همان‌طور که در تصویر بالا مشاهده می‌کنید این سرویس هیچ کنترلری نداشته و تنها با listen کردن به queueها کار می‌کند.در کلاس بالا، توسط RabbitListener Annotation به queue با نام queue.order-create گوش می‌دهیم.هنگامی که مقداری در این queue توسط هر سرویسی publish شد، این annotation فعال شده و تابع handle را اجرا می‌کند.نکته‌ای که در اینجا قابل اشاره است، هنگامی که قصد داریم مقداری را در queueها بفرستیم، می‌بایست به صورت object دارورده و سپس در queue قرار دهیم. همچنین در آن سوی queue این object را مجدد به کلاس خودش convert کنیم.این عملیات convert کردن پیش از ارسال به queue و پس از دریافت از آن را سرویس Shared برعهده دارد.سرویس Stock :این سرویس نیز مانند سرویس‌ payment کنترلری نداشته و تنها با event ها کار می‌کند.ما سعی نمودیم در این پروژه‌ی کاربردی چگونگی پیاده‌سازی و استفاده از الگوی Saga در Microservice را خدمت شما ارائه دهیم.پیشنهاد می‌کنیم جهت درک بهتر، کد را به صورت کامل از صفحه github ما مشاهده نمایید.در صورتی‌که انتقاد و یا پیشنهادی دارید، در قسمت نظرات ما را مطلع نمایید. همچنین می‌توانید برای دسترسی به کدهای بیشتر از سایت ما دیدن کنید.</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Mon, 23 Aug 2021 12:52:53 +0430</pubDate></item><item><title>نمونه کد فروشگاه با spring boot</title><link>https://virgool.ir/@mirbozorgi.com/نمونه-کد-فروشگاه-با-spring-boot-wiwq2ckum7hf</link><description>قصد داریم در این مقاله مختصر توضیحاتی در خصوص پیاده‌سازی یک پروژه فروشگاهی با spring boot را خدمت شما ارائه دهیم.معرفی پروژه :این پروژه یک فروشگاه با قابلیت‌های زیر است :معرفی محصولدسته‌بندی محصولاتامکان کامنت‌گذاریامکان رتبه‌بندی محصول توسط کاربرانمدیریت کاربراناعمال سطح دسترسیفراموشی رمز عبورثبت‌نام دو مرحله‌ایاعمال محدودیت بر دسترسی کاربر (Block)سیستم احراز هویت (JWT)تکنولوژی‌ها :Spring FrameworkPostgreSQLاگر سایر مقاله‌های ما را بررسی کرده کرده باشید، مشاهده می‌کنید که ما از معماری 3Tier layer برای پیاده‌سازی پروژه‌ها استفاده می‌کنیم. در این‌جا نیز قصد داریم از این معماری بهره بگیریم.لایه‌ی Core :همان‌طور که در تصویر مشاهده می‌کنید entity‌های ما شامل موارد زیر است:CategoryCommentProductRateUserSecuritycore layerکلاس Product :product entityهمان‌طور که در تصویر مشاهده می‌کنید ما از کلاس Category یک Relation از نوع OneToOne به کلاس Product ایجاد کردیم.کلاس UserSecurity :userSecurity entityلایه‌ی Business :در این لایه سرویس‌های ما وجود داشته که به اختصار توضیحاتی در مورد مسئولیت‌های آن‌ها، می‌دهیم.یکی از بخش‌هایی که ما از تکنولوژی JWT استفاده می‌کنیم، در هنگام لاگین است. به نمونه کد زیر دقت کنید :ما برای ذخیره پسورد از متد MD5 بهره بردیم که این متد در هنگام ثبت‌نام پسورد را به صورت MD5 ذخیره می‌کند. برای لاگین نیز می‌بایست پسورد ورودی را MD5 کرده و سپس با پسورد ذخیره شده مقایسه کنیم. طبق تصویر اگر تمامی موارد ورودی صحیح باشد، توسط کلاس jwtService یک توکن به کاربر ارجاع می‌دهیم. این توکن جهت درج در header ریکوست، در درخواست‌های بعدی تولید شده است.   jwt create tokenبرای ساخت توکن به موارد زیر نیازمندیم:EmailRoleSecret tokenCreation dateExpire Dateکلاس Auth :ما برای مدیریت هر چه بهتره ریکوست‌ها یک Aspect Oriented Programming (AOP) تعریف کردیم به نام Auth و یک سری تنظیمات به آن اضافه نمودیم که در تصویر مشاهده می‌کنید.نحوه‌ی کار این AOP بدین صورت است که قبل از request قرار می‌گیرد (در معرفی لایه‌ی Api توضیح می‌دهیم) که مسئولیت بررسی دسترسی کاربر به اون api را برعهده دارد.همان‌طور که پیش‌تر گفتیم در هنگام لاگین یک توکن برای کاربر تولید شده که می‌بایست در سایر ریکوست‌ها این توکن در header قرار بگیرد. زمانی‌که ریکوست وارد سیستم می‌شود این annotation توکن را از header خوانده و توسط کلاس jwtService بررسی می‌کند که آیا این توکن دسترسی به ریکوست خواسته‌شده را دارد و یا خیر. لایه‌ی Api :ما برای هر یک از entity های خود یک controller در نظر گرفتیم.طبق تصویر در بعضی ریکوست‌ها annotation Auth قرار دارد که پیش‌تر در مورد آن توضیح دادیم.مسیر مادر در این کلاس category/ بوده و سایر api ها وابسته به کاربردشان دارای مسیر خود هستند. ما سعی نمودیم در این پروژه‌ی کاربردی چگونگی پیاده‌سازی و استفاده از jwt و postgreSQL در محیط Spring Boot را خدمت شما ارائه دهیم. پیشنهاد می‌کنیم جهت درک بهتر، کد را به صورت کامل از صفحه github ما مشاهده نمایید.در صورتی‌که انتقاد و یا پیشنهادی دارید، در قسمت نظرات ما را مطلع نمایید. همچنین می‌توانید برای دسترسی به کدهای بیشتر از سایت ما دیدن کنید.</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Fri, 13 Aug 2021 15:51:41 +0430</pubDate></item><item><title>نمونه کد postgres با spring boot</title><link>https://virgool.ir/@mirbozorgi.com/نمونه-کد-postgres-با-spring-boot-obaxgeu4ob0m</link><description>سلام،حسین کورائی هستم از تیم mirbozorgi.com و قصد دارم مختصر توضیحاتی در خصوص پیاده‌سازی یک پروژه spring boot و نحوه‌ی استفاده از postgreSQL در آن را ارائه دهم.پیاده‌سازی ۳ لایه :در این نمونه کد از متد 3Tier layer برای پیاده‌سازی پروژه استفاده کردم.این روش بدین صورت است که هر لایه به‌صورت جداگانه داری کانفیگ و pom خود است:لایه بندی :همان‌طور که در تصویر بالا مشاهده می‌کنید هر لایه دارای مشخصات خاص خود بوده که در تصاویر زیر نحوه‌ی تنظیم کردن ارتباط بین لایه‌ها را نمایش دادیم:فایل pom لایه api :فایل pom لایه businees :فایل pom لایه core :فایل pom پروژه :همان‌طور که در تصاویر بالا مشاهده می‌کنید لایه‌های بالاتر، لایه‌های زیرین را به عنوان dependency در خود تعریف می‌نمایند و در فایل اصلی، هر module جداگانه تنظیم می‌شود.پیاده‌سازی postgreSQL :در این قسمت می‌خواهیم دیتابیس postgres را در پروژه خود پیاده‌سازی نماییم. پیشنهاد می‌کنم برای کسب اطلاعات بیشتر از این دیتابیس به لینک، مراجعه نمایید.ابتدا dependency این دیتابیس را به فایل pom پروژه اضافه می‌کنیم.در قدم بعد کلاس‌های entity خود را در لایه core پیاده‌سازی می‌کنیم:student :school :exam :همان‌طور که مشاهده می‌کنید در هریک از کلاس‌ها ارتباط های گوناگونی برقرار شده‌است.به عنوان مثال کلاس student ارتباط ManyToOne با کلاس school داشته و همچنین ارتباط ManyToMany با کلاس exam دارد. در سوی دیگر ارتباط OneToMany در کلاس school با کلاس strudent داریم.پیشنهاد می‌کنیم جهت کسب اطلاعات بیشتر در خصوص نحوه‌ی کار و انجام اعمال CRUD بر روی دیتابیس postgreSQL به صفحه github ما مراجعه نمایید.</description><category>mirbozorgi.com</category><author>mirbozorgi.com</author><pubDate>Fri, 16 Jul 2021 19:14:26 +0430</pubDate></item></channel></rss>