مهندسی نرم‌افزار (Software engineering) یعنی استفاده از اصول مهندسی بجا و مناسب برای تولید و ارائه محصول نرم‌افزاری با کیفیت که قابل اطمینان و با صرفه بوده و بر روی ماشین‌های واقعی به‌طور کارآمدی عمل کند.

مهندسی نرم‌افزار عبارت است از کاربرد مهندسی برای طراحی نرم‌افزار، توسعه، پیاده‌سازی و نگهداری از نرم‌افزار در یک روش سیستماتیک.

نرم‌افزار عموماً از محصولات و موقعیت‌هایی شناخته می‌شود که قابلیت اطمینان زیادی از آن انتظار می‌رود، حتی در شرایط طاقت فرسا، مانند نظارت و کنترل نیروگاه‌های انرژی هسته‌ای، یا هدایت یک هواپیمای مسافربری در هوا، چنین برنامه‌هایی شامل هزاران خط کد هستند، که از نظر پیچیدگی با پیچیده‌ترین ماشین‌های نوین قابل مقایسه هستند. به‌عنوان مثال، یک هواپیمای مسافربری چند میلیون قطعه فیزیکی دارد (و یک شاتل فضایی حدود ده میلیون بخش دارد)، در حالی که نرم‌افزارِ هدایت چنین هواپیمایی می‌تواند تا ۴ میلیون خط کد داشته باشد.

مهندسی نرم‌افزار را می‌توان به ۱۵ زیر رشته تقسیم کرد:

• شناخت: بررسی و استخراج نیازمندی‌های نرم‌افزار که شامل استخراج، تحلیل و اعتبارسنجی خواسته‌ها و تهیه مستندات مربوطه جهت طراحی نرم‌افزار می‌باشد.
• طراحی نرم‌افزار: فرایند تعریف معماری، اجزا، واسط و دیگر مشخصه‌های سیستم یا اجزا را گویند. همچنین این زیر بخش به عنوان خروجی فرایند نیز تعریف می‌شود.
• طراحی نرم‌افزار # توجهات طراحی:سازگاری، توسعه پذیری، تحمل خطا، قابلیت نگهداری، ماژولمند بودن، قابلیت اطمینان، قابلیت استفاده مجدد، استحکام، امنیت، قابلیت استفاده، کارایی، قابلیت حمل، مقیاس پذیری.
• ساخت نرم‌افزار:جزئیات مربوط به ایجاد کار با معنی برای نرم‌افزار از طریق برنامه‌نویسی، بازنویسی و تأیید، تست واحدها و اجزا، تست یکپارچگی، و اشکالیابی.
• تست نرم‌افزار: بررسی فنی -تجربی، برای ارائه به سهامداران و ذی نفعان که اطلاعاتی در مورد کیفیت محصول یا خدمات تحت تست بیا ن می‌کند.
• تعمیر و نگهداری نرم‌افزار: کلیه فعالیت‌های مورد نیاز برای ارائه پشتیبانی مقرون به صرفه در نرم‌افزار است.
• مدیریت پیکربندی نرم‌افزار: شناسایی پیکربندی یک سیستم در نقاط مشخصی از زمان به منظور کنترل سیستماتیک تغییرات پیکربندی و حفظ و نگهداری یکپارچگی برنامه و ردیابی پیکربندی در طول چرخه عمر سیستم را گویند.
• مدیریت نرم‌افزارهای مهندسی: نرم‌افزار مدیریت فعالیت‌ها و برنامه‌ریزی، هماهنگی، اندازه‌گیری، نظارت، کنترل و گزارش‌گیری به منظور حصول اطمینان از توسعه و نگهداری سیستماتیک، منضبط و اندازه‌گیری شونده نرم‌افزار است.
• فرایند نرم‌افزار: تعریف، اجرا و پیاده‌سازی، ارزیابی، اندازه‌گیری، مدیریت، ایجاد تغییر و بهبود فرایند چرخه حیات خود نرم‌افزار را گویند.
• روش‌های مهندسی نرم‌افزار و مدل‌های تحمیل ساختار در مهندسی نرم‌افزار با هدف سیستماتیک و منظم کردن فعالیت، قابل تکرار بودن و در نهایت افزایش کیفیت نرم‌افزار و موفقیت امیزتر بودن ان ایجاد می‌شود.
• تمرین مهندسی نرم‌افزار حرفه‌ای دربارهٔ دانش، مهارت و نگرش‌های مهندسی نرم‌افزار است که مهندسان نرم‌افزار باید تمرین مهندسی نرم‌افزار را به صورت حرفه‌ای، مسئولانه و اخلاقی بکنند.
• اقتصاد مهندسی نرم‌افزار در مورد تصمیم‌گیری در زمینه کسب و کار تجاری مهندسی نرم‌افزار است.
• مبانی ریاضی و محاسباتی
• مبانی مهندسی
• ابزار مهندسی نرم‌افزار و روش‌ها: ابزارهایی مبتنی بر کامپیوتر برای مهندسی نرم‌افزار ایجاد شده‌اند تا به فرایندهای چرخه حیات نرم‌افزار و روش‌هایی که ساختاری را بر فعالیت‌های مهندسی نرم‌افزار اعمال می‌کنند کمک کندتا به هدف ساخت فعالیت‌های سیستماتیک و در نهایت به موفقیت بتوان رسید.

کانبان یک سیستم برنامه ریزی اجرای پروزه است

معمولاً کسانی که در حوزه‌ی مدیریت عملیات یا مدیریت پروژه فعالیت دارند، جزئیات بسیاری را در مورد بکارگیری و پیاده سازی این ابزار می‌آموزند.

رویکرد  Kanban :
Kanban یک روش قدرتمند و کاربدی است که از تجسم کار استفاده می کند. کانبان بهترین انتخاب برای استارت اپ ها است چون بسیار سریع میتوان از ان فید بک و بازخورد گرفت . با استفاده از Kanban شما باید بر روی تجسم کار در حال پیشرفت، نگه داشتن گردش کار به شکل ثابت و یادگیری از اشتباهات برای کاهش زمان چرخه های یادگیری تمرکز کنید.

گروه هایی  که از Kanban استفاده می کنند، خیلی سریع تر  در مورد روند کاری خود، به نتایج  ارزشمندی دست پیدا می کنن، نتایجی که به طور چشمگیری سرعت رشد را افزایشمی دهد.  تیم  ها به کمک Kanban می توانند به طور مستمر در حال پیشرفت باشن.

از آنجایی که هر تیم دارای اعضایی با تخصص های متنوع می باشد، تخته کانبان به شما اجازه می دهد تا جریان کاری خود را بر روی آن پیاده کنید. 

5 گام اصلی در کانبان برد:

گام اول،

اولین گام این است کهشما باید از کارها و وظایفی که باید انجام دهید  مطلع باشید تا بتوانید ان را روی برد کاانبان پیاده کنید.

گام دوم،

دومین گام ساخت تخته کانبان است. هنگامی که وظایف و کارهای لازمه را یافتید، باید آنها را در بردکانبان وارد کنید. سه ستون اصلی (باید انجام شودTO DO، در حال انجام DONIGو انجام شدهDONE) تخته کانبان را رسم کنید و وظایف را در آن قرار دهید. تخته کانبان در اوایل کار بسیار متغیر خواهد بود و پس از گذشت زمان به مرور ثابت می شود.

گام سوم

 اضافه کردن محدودیت WIP (کار در حال انجام) می باشد. محدودیت WIP یک عدد است که برای ستون ها (در حال انجام، آزمایش، اجرا، و غیره) معین می شود که نشان می دهد چه تعداد وظیفه می تواند در ستون قرار داشته باشد. اگر ستون پر شود، هیچ کار اضافی نمی تواند اضافه شود. محدودیت های WIP بخش مهمی از روش کانبان هستند زیرا این محدودیت ها باعث می شوند تیم مرتبا پربازده باقی ماند. با ایجاد محدودیت در تعداد وظایف، اعضای تیم تا زمانی که وظیفه مربوط به خود را انجام نداده اند نمی توانند سراغ کارها و وظایف جدید بروند. 

گام چهارم

جلسات کوتاه روزانه می تواند یکی از بزرگترین فرصت های شما برای شناسایی مشکلات و یافتن راه حل ها باشد. هدف جلسه روزانه، بحث درباره مشکلات تیم  و حل آنهاست. جلسات برنامه ریزی باید فقط در صورت وم برگزار شوند و به بحث درباره پروژه های آینده و گذشته بپردازد.

گام پنجم 

برای شروع Kanban درج گزارش می باشد.این گزارش ها برای کمک به شما برای یافتن اطلاعاتی مانند چند روز طول می کشد تا یک وظیفه به پایان برسد، تعداد کارهایی که تیم در یک زمان می تواند انجام دهد .گزارشات و بازخوردها به شما یک بینش عالی برای بهبود روند کاریتان ارائه می دهد.

در تصویر زیر یک نمونه بسیار ساده از تخته کانبان را مشاهده می کنید:

رنگ کارت نیز می تواند به اولویت آن وظیفه نیز اشاره کند (به عنوان مثال، قرمز برای سرعت بخشیدن، سبز برای عادی و غیره).

به هیچ عنوان چه وبلاگ و چه وبسایت از مطالب کپی شده از منابع دیگر قرار ندهید زیرا گوگل با هوش مصنوعی خود توانایی شناخت منبع و حتی درصد کپی شدن رو دارد و در نتیجه برای شما امتیاز منفی داده می شود و در صوورت تکرار بیشتر سایت پنالتی می شود پس سعی شود در توالید محتوا 

از صفر کار تایب رو انجام دهید این امر در مورد تصاویدر هم صدق می کند .

توسعه چابک نرم‌افزار یا توسعه نرم‌افزاری چابک گروهی از متدهای توسعهٔ نرم‌افزار مبتنی بر تکرار و به شکل تدریجی است که در آنها، راه‌حل‌ها از طریق خودسازمان‌دهی و همکاری بین تیم‌های مختلف کاری، انجام می‌شوند. این روش برنامه‌ریزی تطبیقی، توسعه و تحویل تکاملی و رویکرد زمان بسته‌بندیِ تکرارشونده را ارتقا می‌بخشد و پاسخ‌های سریع و انعطاف‌پذیر برای انجام تغییرات را تقویت می‌کند. در واقع چابک‌سازی یک چارچوب مفهومی است که پیش‌بینی تعاملات در سراسر چرخهٔ توسعه را بهبود می‌بخشد.

متدهای توسعهٔ چابک مشخص زیادی وجود دارند، که بیشترشان توسعه، کار تیمی، همکاری و سازگاری فرایند در چرخهٔ حیات پروژه را ترفیع می‌دهند. متدهای چابک وظایف را به گام‌های کوچک با کمترین میزان برنامه‌ریزی می‌شکنند که به‌طور مستقیم با برنامه‌ریزی‌های طولانی‌مدت درگیر نیستند. تکرارها فریم‌های (بسته‌های زمانی) کوتاه‌مدتی هستند که معمولاً بین یک تا چهار هفته طول می‌کشند. هر تکرار دارای یک تیم متقابل عملکردی در تمام مأموریت‌ها است: تحلیل نیازمندی‌ها، طراحی، کدنویسی، واحد تست، و قبولی در تست. در پایان هر تکرار یک محصول کاری به ذی‌نفعان نشان داده می‌شود. این، ریسک کلی را به حداقل رسانده و اجازه می‌دهد پروژه خیلی سریع با تغییرات منطبق شود. ممکن است یک تکرار قابلیت کافی برای تضمین پخش در بازار را نیفزاید، اما هدف، انتشار در دسترس (با حداقل شکاف) در پایان هر تکرار است. شاید تکرارهای چندگانه نیاز به انتشار یک محصول یا ویژگی‌های جدید داشته باشند. ترکیب تیم در یک پروژهٔ چابک معمولاً عملکردی متقابل و خودسازمان‌دهی است، بدون توجه به هرگونه سلسله‌مراتب شرکتی یا نقش‌های شرکتی اعضای تیم. اعضای تیم به‌طور معمول مسئولیت وظایفی را که قابلیت نیازهای تکرار را ارائه می‌دهد، بر عهده می‌گیرند. آن‌ها به صورت جداگانه تصمیم می‌گیرند که چگونه با نیازمندی‌های یک تکرار مواجه شوند.

متدهای چابک، وقتی تیم‌ها با هم در یک مکان هستند، بر ارتباطات رو در رو برای تمام مستندات نوشته‌شده تأکید دارد. بیشتر تیم‌های چابک در یک دفتر تک‌واحدی (به نام bullpen) کار می‌کنند، که چنین ارتباطاتی را تسهیل می‌کند. به منظور ساده کردن ارتباطات و همکاری تیمی، گروه معمولاً کوچک (بین ۵ تا ۹ نفره) است. پروژه‌های بزرگ توسعه می‌توانند توسط تیم‌های کاری چندگانه در راستای یک هدف رایج یا در بخش‌های متفاوت یک پروژه تحویل شوند. ممکن است این امر نیاز به هماهنگی اولویت‌های تمام تیم‌ها داشته باشد. وقتی تیمی در مکان‌های مختلفی کار می‌کند، افراد ارتباط روزانه‌شان را از طریق ویدئو کنفرانس، صدا، ایمیل و. حفظ می‌کنند.

مهم نیست چه دیسیپلین‌های توسعه‌ای لازم است، هر تیم چابک، یک پاسخگوی مشتری دارد. این شخص توسط ذی‌نفعان به نمایندگی انتخاب می‌شود و یک تعهد فردی ایجاد می‌کند که برای پاسخگویی به سؤالات اواسط تکرار، در دسترس توسعه‌دهندگان باشد.در انتهای هر تکرار، ذی‌نفعان و نمایندهٔ مشتریان پیشرفت را بررسی می‌کنند، اولویت‌ها را با دید بهینه‌سازی بازگشت سرمایه (ROI) مجدداً می‌سنجند و از انطباق نیازهای مشتری با اهداف شرکت اطمینان حاصل می‌کنند. بیشتر پیاده‌سازی‌های چابک از ارتباطات غیررسمی، روزانه و رو در رو در میان اعضای تیم بهره می‌گیرند. این به‌طور خاص شامل نمایندهٔ مشتری و هر کدام از ذی‌نفعان علاقه‌مند به عنوان ناظر می‌شود. در یک جلسهٔ مختصر، هر کدام از اعضای تیم گزارش می‌دهند که در روز گذشته چه کرده‌اند، قصد دارند در روز جاری چه کارهایی انجام دهند و موانع پیش روی‌شان کدامند. این ارتباطات رو در رو مشکلات را به محض بروز، افشا می‌کند. «این جلسات روزانه، گاهی به صورت ایستاده یا نشست‌های اسکرام هر روز در یک زمان و مکان ثابت برگزار می‌شوند و نباید بیش از ۱۵ دقیقه طول بکشند. معمولاً جلسات ایستاده این نقش را دارند.»

توسعهٔ چابک بر کار نرم‌افزار به عنوان مقیاس اصلی پیشرفت تأکید دارد، که با مزیت ارتباطات رو در رو در هم آمیخته شده، و نسبت به سایر متدها مستندات مکتوب کمتری تولید می‌شود. متد چابک ذی‌نفعان را به اولویت‌بندی «خواسته‌ها» با نتایج حاصل از سایر تکرارها، بر اساس ارزش کسب‌وکار مشاهده‌شده در ابتدای تکرار (که با عنوان ارزش‌محور شناخته می‌شود) ترغیب می‌کند.

ابزارها و تکنیک‌های خاص، مانند یکپارچه‌سازی مستمر، تست اتوماتیک یا xUnit، برنامه‌نویسی دوجزئی، توسعهٔ آزمون‌محور، الگوهای طراحی، طراحی دامنه‌محور، code refactoring و دیگر تکنیک‌ها اغلب برای بهبود کیفیت و افزایش چابکی پروژه به کار می‌روند.

توسعهٔ کمی‌چابک (LAD) چاشنی متدولوژی چابک است که تکنیک‌های دست‌چین را (از طیف وسیع‌تری از پروژه‌های چابک) برای شرکت‌های مناسب مختلف، تیم‌ها، موقعیت‌ها و محیط‌های توسعه به کار می‌بندد. یکی دیگر از جنبه‌های کلیدی LAD متمایل به کاربرمحور بودن است، در درجهٔ اول بر تجارب کاربر و واسط‌های نرم‌افزاری قابل‌استفاده تمرکز می‌کند و برای تحویل آن‌ها متدولوژی‌های چابک را به کار می‌بندد. بیشتر پیاده‌سازی‌های چابک دنیای واقعی در عمل واقعاً LAD هستند، چون ارزش اصلی متدولوژی به انعطاف‌پذیری، معقول بودن و تمرکز بر کارهایی که انجام شده، است.

در توسعهٔ چابک نرم‌افزار، یک رادیاتور اطلاعات، صفحه‌نمایشی فیزیکی (معمولاً بزرگ) واقع در صدر دفتر کار است، جایی که رهگذران بتوانند آن را ببینند. این صفحه‌نمایش خلاصه‌ای از آخرین وضعیت محصول (های) نرم‌افزاری را نمایش می‌دهد. این نام توسط Alistair Cockburn ابداع و در کتاب «توسعهٔ چابک نرم‌افزار» در سال ۲۰۰۲ توصیف شد.ممکن است یک نشانگر نوری برای آگاه کردن اعضای تیم در مورد وضعیت فعلی پروژه‌شان به کار رود.

متدهای معروف توسعهٔ چابک نرم‌افزار عبارتند از:

• مدل‌سازی چابک
• فرایند یکپارچهٔ چابک (AUP)
• Crystal Clear
• متدهای Crystal
• متدهای توسعهٔ سیستم‌های دینامیک (DSDM)
• برنامه‌نویسی اکستریم (XP)
• توسعهٔ ویژگی‌محور (FDD)
• طراحی گرافیکی سیستم (GSD)
• توسعه Kanban
• توسعه Lean
• Scrum
• ردیابی سرعت

چرخهٔ عمر توسعهٔ نرم‌افزار

متدهای چابک بر جنبه‌های متفاوتی از چرخهٔ عمر توسعهٔ نرم‌افزار تمرکز دارند. بعضی از آن‌ها بر روش‌ها (برنامه‌نویسی extreme، برنامه‌نویسی فعال مدل‌سازی چابک) تمرکز دارند، در حالی که بعضی دیگر بر مدیریت پروژه‌های نرم‌افزاری تأکید دارند (مانند رویکرد Scrum ). هنوز، رویکردهایی وجود دارند که تمام چرخهٔ عمر توسعه را پوشش می‌دهند (متدهای توسعهٔ سیستم دینامیک (DSDM) و Rational Unified Process (RUP))، در حالی که بیشتر آن‌ها از فاز تعیین نیازمندی‌ها مناسب هستند (مثلاً ویژگی‌محور در توسعه یا FDD). بنابراین، یک تفاوت آشکار بین متدهای گوناگون توسعهٔ چابک نرم‌افزار در این مورد است. اگرچه DSDM و RUP نیازی به رویکردهای مکمل برای پشتیبانی از توسعهٔ نرم‌افزار ندارند، بقیهٔ آن‌ها با درجات متفاوت این نیاز را دارند. DSDM می‌تواند توسط هر کسی به کار رود (علیرغم اینکه فقط اعضای DSDM می‌توانند محصولات یا خدمات DSDM را عرضه کنند). RUP یک محیط توسعه تجاری فروشی است (Abrahamsson، Salo، Rankainen & Warsta، 2002).

نقد

ممکن است متدولوژی‌های چابک در سازمان‌های بزرگ و انواع خاصی از پروژه‌ها ناکارآمد باشند.

متدهای چابک برای پروژه‌های توسعه‌ای و غیردائمی بهتر به نظر می‌رسد. بسیاری از سازمان‌ها باور دارند متدولوژی‌های چابک بسیار قوی هستند و با یک رویکرد مخلوط که ترکیبی از المان‌های رویکردهای چابک و برنامه‌محور است، سازگار می‌شوند.

۱- طراحی ساده ای انتخاب کنید.

۲- محتوا در مرکز صفحه قرار می گیرد.

۳- توجه بیشتر بر روی ظاهر و شکل محتواست تا ظاهر و طراحی صفحه.

۴- توجه بیشتر بر استفاده از فضای سفید.

۶- استفاده مؤثر از رنگ ها.

۷- متن و فونت بزرگ.

۸- استفاده بیشتر از تصاویر و ویدئو ها.

۹- استفاده از المان های طراحی عامه پسند.

۱۰- تاکید بر قابل دسترس بودن.

شناسایی دیتا بیس برای لاراول

فایل env. را کلیک می کینم

db port: 3307

db data base: نام دیتا بیس

چگونه با لاراول تیبل بسازیم 

ترمینال را در مسیر پرزوه استارت می کنیم

و دستور زیر و اجرا می کنیم

 نام تیبلphp artisan make :migration create_t

   و تغییر انجین دیتا بیس

فایل دیتا بیس در پوشه کانفیگ خط 46 قسمت  my sql 

engine-> InnoDB

اسم موتور رو می نویسیم

سپس در اخر در ترمینال فرمان 

php artisan migrate 

را تایپ می کنیم

پکیجlaravel go to

laravel go to view

laravel go to contrller

1dark raincoat

archivos laravel

auto close tag

auto complate tag

auto raname tag

auto raname tagbeautify css/sass/scss/less

beauty
better comments

bootstrap4 , font

can i use

class autocomplete for HTML

csscomb

debugger for chrome

dotENV

editorconfig for vs
EJS language support

eslint

expressjs

format html in php

formatter-pug

git history

html snippets

intelisence for css class names in html

itmcdev generic extnsion pack

itmcdev html/css extnsion pack

laravel 5 snippets

laravel 5.6 snippets

laravel artisan

laravel assist

laravel blade snippets

laravel helpers

laravel model snippets

laravel sinp 

laravel snippets pro

laravel-5-snippets

larvel-blade
laravel-goto-controller

less intelisense

live share

live share audio

live share chat

live share extension pack

live share whiteboard

markdown all in one

material icon theme

mongo snippets for node

mustache

node.js extension pack

node.js modules intelisense

nodejs module snippet

nodejs snippets

npm

npm intlisense

one dark pro

path intelisense

php debug

php extension pack

php intelisense

php namespace resolver

php snippets from phpstorm

php xdebug

prettier - code formatter

pug (jade) snippets

pug\jade bootsrap, font awesome snippets

ra shadow

sass lint

scss intlisense

search node-modules

simple icons

sublime text keymap and setting importer

simple iconssuper  one dark theme

teminal tabs

vetur

vs code counter

vs code for node.js development pack

windows opacity

مدل ها در لاراول در داخل پوشه app وجد ارند 

دستور ایجاد مدل سی ام دی مربوط به مدل 

نام مدل php artisam make:model

برای نام مدل کافی است از اسم تیبل مربوط به ان حرف s را حذف کرده و حرف اول ان را کپتال بنویسم تا لاراول خودی خود مدل و تنبل را به هم کانتکت کند

نکته 

هر جا بخواهیم از مدل استفاده کنیم بالای صفحه باید نیم اسپیس (اسم کلاس)ان مدل را یوز کنیم

Laravel چندین روش مختلف برای تأیید اعتبار داده های ورودی برنامه شما ارائه می دهد. به طور پیش فرض ، کلاس کنترلر پایه لاراول از یک صفت ValidatesRequests استفاده می کند که روشی مناسب برای اعتبارسنجی درخواستهای HTTP ورودی با انواع قوانین اعتبار سنجی قدرتمند ارائه می دهد.

تعریف مسیرها:

ابتدا فرض کنیم مسیرهای زیر را در پرونده خود تعریف کرده ایم:

Route::get('post/create', 'PostController@create');

Route::post('post', 'PostController@store');

مسیر GET فرم ایجاد وبلاگ جدید را برای کاربر نمایش می دهد ، در حالی که مسیر POST پست جدید وبلاگ را در پایگاه داده ذخیره می کند.

ایجاد کنترلر
بعد ، بیایید نگاهی بیندازیم به یک کنترلر ساده که این مسیرها را کنترل می کند. اکنون روش store را خالی می گذاریم:

<?php

namespace App\Http\Controllers;

use App\Http\Controllers\Controller;
use Illuminate\Http\Request;

class PostController extends Controller
{
    /**
     * Show the form to create a new blog post.
     *
     * @return Response
     */
    public function create()
    {
        return view('post.create');
    }

    /**
     * Store a new blog post.
     *
     * @param  Request  $request
     * @return Response
     */
    public function store(Request $request)
    {
        // Validate and store the blog post.
    }
}

 نوشتن منطق اعتبار سنجی
اکنون ما آماده هستیم تا روش STORE خود را با این منطق برای اعتبارسنجی پست وبلاگ جدید پر کنیم. برای این کار از روشی معتبر تهیه شده توسط شی Illuminate \ Http \ Request استفاده خواهیم کرد. اگر قوانین اعتبارسنجی تصویب شوند ، کد شما اجرای خود را به صورت عادی ادامه می دهد. اما اگر اعتبار سنجی انجام نشود ، یک استثناء انداخته می شود و پاسخ خطایی مناسب به طور خودکار به کاربر ارسال می شود. در صورت درخواست سنتی HTTP ، یک پاسخ تغییر مسیر ایجاد می شود ، در حالی که یک پاسخ JSON برای درخواست های AJAX ارسال می شود.

برای درک بهتر روش VALIDATE ، بیایید دوباره به روش STORE برویم:

/**
 * Store a new blog post.
 *
 * @param  Request  $request
 * @return Response
 */
public function store(Request $request)
{
    $validatedData = $request->validate([
        'title' => 'required|unique:posts|max:255',
        'body' => 'required',
    ]);

    // The blog post is valid.
}

همانطور که مشاهده می کنید ، قوانین اعتبارسنجی مورد نظر را به روش VALIDATE منتقل می کنیم. باز هم ، اگر اعتبار سنجی انجام نشود ، پاسخ مناسب به طور خودکار ایجاد می شود. اگر اعتبار سنجی بگذرد ، کنترلر ما به طور معمول اجرای خود را ادامه می دهد.

از طرف دیگر ، قوانین اعتبارسنجی ممکن است به جای یک تک به عنوان آرایه ای از قوانین مشخص شوند | رشته نامحدود:

$validatedData = $request->validate([
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

اگر مایل هستید ERROR BAG را که پیام های خطا در آن قرار داده شده است ، مشخص کنید ، می توانید از روش validateWithBag استفاده کنید:

$request->validateWithBag('blog', [
    'title' => ['required', 'unique:posts', 'max:255'],
    'body' => ['required'],
]);

متوقف کردن اولین عدم موفقیت اعتبارسنجی:
بعضی اوقات ممکن است بخواهید بعد از اولین خرابی اعتبار ، اجرای قوانین اعتبارسنجی را روی یک ویژگی متوقف کنید. برای این کار ، قانون BAIL را به این ویژگی اختصاص دهید:

$request->validate([
    'title' => 'bail|required|unique:posts|max:255',
    'body' => 'required',
]);

در این مثال ، اگر قانون UNIQUE روی ویژگی TITLE خراب شود ، قانون MAX بررسی نمی شود. قوانین به ترتیبی که تعیین شده اند معتبر خواهند بود.

یادداشت در مورد ویژگی های تو در تو
اگر درخواست HTTP شما حاوی پارامترهای "تو در تو" است ، می توانید آنها را در قوانین اعتبار خود با استفاده از نحو "نقطه" مشخص کنید:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'author.name' => 'required',
    'author.description' => 'required',
]);

خطاهای اعتبار سنجی
بنابراین ، اگر پارامترهای درخواست ورودی ، قوانین اعتبارسنجی داده شده را تصویب نکنند ، چه می شود؟ همانطور که قبلاً نیز گفته شد ، Laravel به طور خودکار کاربر را به مکان قبلی خود هدایت می کند. علاوه بر این ، تمام خطاهای اعتبارسنجی به طور خودکار به جلسه چشمک می زنند.

باز هم توجه کنید که ما در مسیر GET خود مجبور نبودیم پیغامهای خطا را به طور صریح به نمایش پیوند دهیم. این امر به این دلیل است که Laravel خطاهای موجود در داده های جلسه را بررسی می کند و در صورت موجود بودن آنها را به طور خودکار به نمایش متصل می کند. متغیر $ ERROR نمونه ای از Illuminate \ Support \ MessageBag خواهد بود.

متغیر ERROR$ توسط واسطه بین المللی Illuminate \ View \ Middleware \ ShareErrorsFromSession ، که توسط گروه وب MIDDLEWARE تهیه شده است ، به نمای محدود می شود. هنگامی که این میان افزار اعمال می شود ، یک متغیر ERROR$ همیشه در دیدگاه های شما موجود می باشد ، به شما امکان می دهد فرض کنید متغیر ERROR$ به راحتی همیشه تعریف شده است و می توانید با خیال راحت از آن استفاده کنید.

بنابراین ، در مثال ما ، کاربر در صورت عدم موفقیت اعتبار به کاربر ، به روش ایجاد کنترلر ما هدایت می شود و به ما اجازه می دهد تا پیام های خطا را در نمای نمایش دهیم:

<!-- /resources/views/post/create.blade.php -->

<h1>Create Post</h1>

@if ($errors->any())
    <div class="alert alert-danger">
        <ul>
            @foreach ($errors->all() as $error)
                <li>{{ $error }}</li>
            @endforeach
        </ul>
    </div>
@endif

<!-- Create Post Form -->

یادداشت در زمینه های اختیاری
به طور پیش فرض ، Laravel شامل واسط TrimStrings و ConvertEmptyStringsToNull در پشته جهانی برنامه جهانی برنامه شما است. این وسایل واسط طبق برنامه App \ Http \ Kernel در پشته ذکر شده اند. به همین دلیل ، اگر نمی خواهید اعتبارگر مقادیر NULL را نامعتبر در نظر بگیرد ، اغلب باید زمینه های درخواست "اختیاری" خود را به عنوان NULLABLE علامت گذاری کنید. مثلا:

$request->validate([
    'title' => 'required|unique:posts|max:255',
    'body' => 'required',
    'publish_at' => 'nullable|date',
]);

در این مثال ، ما مشخص می کنیم که قسمت bot_at ممکن است NULL یا یک تاریخ معتبر باشد. اگر اصلاح کننده NULLABLE به تعریف قانون اضافه نشود ، اعتبار دهنده NULL را یک تاریخ نامعتبر می داند.

درخواستها و اعتبار سنجی AJAX:
در این مثال ، ما برای ارسال داده به برنامه از یک فرم سنتی استفاده کردیم. با این حال ، بسیاری از برنامه ها از درخواست های AJAX استفاده می کنند. هنگام استفاده از روش VALIDATE در طی درخواست AJAX ، Laravel پاسخی برای تغییر مسیر ایجاد نمی کند. در عوض ، Laravel یک پاسخ JSON تولید می کند که حاوی همه خطاهای اعتبارسنجی است. این پاسخ JSON با کد وضعیت 422 HTTP ارسال می شود.

اعتبار درخواست فرم