آشنایی با Anaemic Domain Model و Rich Domain Model
یک Anaemic Domain Model به مدلی (کلاس) گفته میشود که فقط دارای خصوصیات است و از خودش رفتاری ندارد. در واقع یک سری Property دارد بدون آنکه متدی درونش تعریف شده باشد.
طبیعی است که این نوع مدل ها امکان اعتبار سنجی از داده های خود را ندارند. معمولا وقتی از یک ADM استفاده می کنید لایه ی سرویس عملیات Validation ، Business Logic را انجام میدهد. که نتیجه اش داشتن لایه سرویس قطور با انبوه کد است.
در مقابل Rich Domain Model سهم بیشتری از عملیات را درون خود انجام میدهد و سعی می کند بر مبنای برنامه نویسی شی گرا حداکثر استفاده را از قابلیت های یک Class ببرد. در نتیجه Service Layer کوچکتر شده و یا ممکن است اصلا وجود نداشته باشد.
در بسیاری موارد ADM یک Anti-pattern شناخته میشود . مخصوصا اگر Business Logic در پروژه پیچیده باشد مدیریت کردن داده ها به صورت فرآیندی ( متدها) مشکل میشود. اما این مسئله مطلق نیست. اگر بخواهیم اصول SOLID را در برنامه نویسی در نظر بگیریم داشتن یک کلاس که همه کار انجام میدهد با اصلی که می گوید هر کلاس تنها و تنها باید مسئول انجام یک کار باشد در تضاد است.
در نهایت شما باید به هدف فکر کنید. باید بسنجید با توجه به شرایط موجود کدام روش مناسب است. آیا پروژه خود را بر اساس مفاهیم و الگوها پیاده می کنید یا از الگوها و مفاهیم برای پیاده سازی پروژه خود استفاده می کنید ؟
یک Anaemic Domain Model به مدلی (کلاس) گفته میشود که فقط دارای خصوصیات است و از خودش رفتاری ندارد. در واقع یک سری Property دارد بدون آنکه متدی درونش تعریف شده باشد.
طبیعی است که این نوع مدل ها امکان اعتبار سنجی از داده های خود را ندارند. معمولا وقتی از یک ADM استفاده می کنید لایه ی سرویس عملیات Validation ، Business Logic را انجام میدهد. که نتیجه اش داشتن لایه سرویس قطور با انبوه کد است.
در مقابل Rich Domain Model سهم بیشتری از عملیات را درون خود انجام میدهد و سعی می کند بر مبنای برنامه نویسی شی گرا حداکثر استفاده را از قابلیت های یک Class ببرد. در نتیجه Service Layer کوچکتر شده و یا ممکن است اصلا وجود نداشته باشد.
در بسیاری موارد ADM یک Anti-pattern شناخته میشود . مخصوصا اگر Business Logic در پروژه پیچیده باشد مدیریت کردن داده ها به صورت فرآیندی ( متدها) مشکل میشود. اما این مسئله مطلق نیست. اگر بخواهیم اصول SOLID را در برنامه نویسی در نظر بگیریم داشتن یک کلاس که همه کار انجام میدهد با اصلی که می گوید هر کلاس تنها و تنها باید مسئول انجام یک کار باشد در تضاد است.
در نهایت شما باید به هدف فکر کنید. باید بسنجید با توجه به شرایط موجود کدام روش مناسب است. آیا پروژه خود را بر اساس مفاهیم و الگوها پیاده می کنید یا از الگوها و مفاهیم برای پیاده سازی پروژه خود استفاده می کنید ؟
اصل حداقل شگفتی
در طراحی مهندسی Principle of least astonishment یا اصل حداقل شگفتی به تلاش برای عدم سورپرایز کردن کاربر سیستم تعریف میشود.
مثلا در سیستم عامل ویندوز وقتی دکمه ی F1 کیبورد را میزنید انتظار دارید که صفحه ی راهنما نرم افزار یا سیستم عامل را مشاهده کنید. اگر می خواهید اصل حداقل شگفتی را رعایت کرده باشید نباید برای F1 کاربرد دیگری تعریف کنید.
این اصل بیان می کند که کاربر سیستم باید با آن چیزی که انتظار دارد برخورد کند به طوریکه نیاز به راهنما نداشته باشد. با این تکنیک سرعت یادگیری کار با سیستم افزایش میابد و منابع کمتری برای آموزش هدر میرود.
این اصل در برنامه نویسی هم اهمیت زیادی دارد. کدها باید گویا باشد و متدها نباید به گونه ای رفتار کنند که کاربر (در اینجا برنامه نویس) را سردرگم کند. در واقع یک متد تنها باید کاری را انجام دهد که در اسمش آمده و نه هیچ کار دیگری. از طرف دیگر استفاده از تکنیک ها خلاقانه برای حل مشکل باید به حداقل برسد. وقتی در یک تیم کار می کنید یا افراد دیگری باید کدهای شما را بررسی کنند راه حل های غیر متعارف می تواند میزان پیچیدگی کد را بالا ببرد و فهم آن را برای همه مشکل کند.
در طراحی مهندسی Principle of least astonishment یا اصل حداقل شگفتی به تلاش برای عدم سورپرایز کردن کاربر سیستم تعریف میشود.
مثلا در سیستم عامل ویندوز وقتی دکمه ی F1 کیبورد را میزنید انتظار دارید که صفحه ی راهنما نرم افزار یا سیستم عامل را مشاهده کنید. اگر می خواهید اصل حداقل شگفتی را رعایت کرده باشید نباید برای F1 کاربرد دیگری تعریف کنید.
این اصل بیان می کند که کاربر سیستم باید با آن چیزی که انتظار دارد برخورد کند به طوریکه نیاز به راهنما نداشته باشد. با این تکنیک سرعت یادگیری کار با سیستم افزایش میابد و منابع کمتری برای آموزش هدر میرود.
این اصل در برنامه نویسی هم اهمیت زیادی دارد. کدها باید گویا باشد و متدها نباید به گونه ای رفتار کنند که کاربر (در اینجا برنامه نویس) را سردرگم کند. در واقع یک متد تنها باید کاری را انجام دهد که در اسمش آمده و نه هیچ کار دیگری. از طرف دیگر استفاده از تکنیک ها خلاقانه برای حل مشکل باید به حداقل برسد. وقتی در یک تیم کار می کنید یا افراد دیگری باید کدهای شما را بررسی کنند راه حل های غیر متعارف می تواند میزان پیچیدگی کد را بالا ببرد و فهم آن را برای همه مشکل کند.
در ASP Core یک سیستم تزریق وابستگی کم حجم و ساده پیاده شده است که نیاز به استفاده از سایر IoC ها از قبیل StructureMap و Ninject یا AutoFac را از بین میبرد. به طور کلی می توان به سه روش کلاسها (سرویسها) را در این فریم ورک تزریق کرد.
1- حالت Transient
در این روش سرویس در هربار که فراخوانی شود ایجاد میشود.
2- حالت Scoped
در این روش سرویس به ازای هر Request تنها یکبار ایجاد میشود.
3- حالت Singleton
در این روش سرویس تنها در اولین فراخوانی ایجاد میشود و در دفعات بعد از همان سرویس استفاده میشود.
1- حالت Transient
در این روش سرویس در هربار که فراخوانی شود ایجاد میشود.
2- حالت Scoped
در این روش سرویس به ازای هر Request تنها یکبار ایجاد میشود.
3- حالت Singleton
در این روش سرویس تنها در اولین فراخوانی ایجاد میشود و در دفعات بعد از همان سرویس استفاده میشود.
کنترلر در ASP Core
در ASP NET Core یک کلاس درصورتی به عنوان کنترلر شناخته میشود که حداقل دارای یکی از شرایط زیر باشد.
1- نام کلاس دارای پسوند Controller باشد
2- از کلاسی ارث بری کند که آن کلاس دارای پسوند Controller باشد.
3- با اتریبیوت [Controller] مشخص شده باشد.
همچنین نباید دارای اتریبیوت [NonController] باشد.
در ASP NET Core یک کلاس درصورتی به عنوان کنترلر شناخته میشود که حداقل دارای یکی از شرایط زیر باشد.
1- نام کلاس دارای پسوند Controller باشد
2- از کلاسی ارث بری کند که آن کلاس دارای پسوند Controller باشد.
3- با اتریبیوت [Controller] مشخص شده باشد.
همچنین نباید دارای اتریبیوت [NonController] باشد.
اکشن ها در ASP Core
در ASP Core اکشن دارای خروجی IActionResult است که در مقایسه با نسخه ی قبلی دامنه ی گسترده ای را پوشش میدهد. با ترکیب شدن Web API درون MVC اکنون می توان پیامهای HTTP مانند BadRequest یا OK را مستقیما به کاربر برگشت داد. در نسخه ی جدید کلاس ApiController دیگر وجود ندارد.
همه ی متدهای Public درون کنترلر یک Action محسوب میشوند مگر اینکه با [NonAction] علامتگذاری شده باشند.
پارامترهای تعریف شده در یک اکشن به صورت خودکار با Model Binding پردازش میشوند و ModelState.IsValid در این نسخه مانند MVC5 عمل میکند.
در ASP Core اکشن دارای خروجی IActionResult است که در مقایسه با نسخه ی قبلی دامنه ی گسترده ای را پوشش میدهد. با ترکیب شدن Web API درون MVC اکنون می توان پیامهای HTTP مانند BadRequest یا OK را مستقیما به کاربر برگشت داد. در نسخه ی جدید کلاس ApiController دیگر وجود ندارد.
همه ی متدهای Public درون کنترلر یک Action محسوب میشوند مگر اینکه با [NonAction] علامتگذاری شده باشند.
پارامترهای تعریف شده در یک اکشن به صورت خودکار با Model Binding پردازش میشوند و ModelState.IsValid در این نسخه مانند MVC5 عمل میکند.
شبیه سازی خطای NotFound یا 404 با استفاده از یک اکشن فیلتر در ASP MVC 5
لینک گیست :
https://gist.github.com/codehaks/d4172388f869956e79e932b2763504bf
لینک گیست :
https://gist.github.com/codehaks/d4172388f869956e79e932b2763504bf
کدهک
شبیه سازی خطای NotFound یا 404 با استفاده از یک اکشن فیلتر در ASP MVC 5 لینک گیست : https://gist.github.com/codehaks/d4172388f869956e79e932b2763504bf
در پروژه های Live گاهی لازم میشود یک بخش از سایت را سریع از سرویس خارج کنید. یک روش حذف فایلهای مربوط به آن بخش است. اما وقتی یک تیم همزمان روی پروژه کار میکندحذف کردن فایل ممکن است عواقب پیش بینی نشده ی زیادی داشته باشد. همچنین شاید در آینده بخواهید این قسمت را دوباره به سرویس برگردانید یا حتی باگی در کار باشد که مجبور شوید به نسخه ی قبلی سویچ کنید.
یک راه ساده و سریع این است که با استفاده از یک اکشن فیلتر تمام درخواستهایی که به کنترلر مربوط ارسال میشود مسدود کنید. در این تکنیک خطای 404 ایجاد میشود و بقیه ی کار به سیستم مدیریت خطا واگذار میشود.
یک راه ساده و سریع این است که با استفاده از یک اکشن فیلتر تمام درخواستهایی که به کنترلر مربوط ارسال میشود مسدود کنید. در این تکنیک خطای 404 ایجاد میشود و بقیه ی کار به سیستم مدیریت خطا واگذار میشود.
آموزش برنامه نویسی در ASP.NET Core 2.0 آموزش #C و تکنیک های پیشرفته در کد نویسی Web Development
https://www.aparat.com/codehaks
https://www.aparat.com/codehaks
آپارات - سرویس اشتراک ویدیو
آپارات | کدهک
آموزشگاه تخصصی دات نت
مطمئنا خیلی جاها خوندین که استفاده از Repositroy و Unit of work اشتباه هست..چون خود DbContext حکم همین داستان رو داره.
این یک اشتباه رایج در مورد نحوه ی کار DbContext و الگوی Repository هست. مارتین فاولر در کتاب Patterns of Enterprise Application Architecture که در تعریف الگوی Repository میگه :
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object
collection.
که مشخصا اشاره میکنه به اینکه Repository یک واسط بین Domain و Data Mapper هست که Domain همون مدلها و سرویسهاست و Data Mapper همون DbContext هست.
در واقع DbContext اطلاعات رو در حافظه ذخیره نمیکنه و برای اجرای هر عملیاتی به سراغ دیتابیس میره . اما Repository قراره داده هارو درون متغیرهای محلی ذخیره کنه که سرعت دسترسی به اونها بیشتر بشه. نقش Unit Of Work اینه که این حافظه ی موقت ایجاد شده رو زنده نگه داره و جلوی ازبین رفتنش رو بگیره تا بشه همیشه خیلی سریع به داده ها دسترسی داشت.
خروجی متدهای DbContext از نوع IQueryable هست. که در واقع یک کوئری هست و نه خود داده ها. یعنی داده ها قبل از اجرای متد وجود ندارن و در لحظه ای که خط داره اجرا میشه از دیتابیس جمع آوری میشن.
ولی در Repository از IList استفاده میشه. که نوع خاصی از آرایه هست که اطلاعات رو در حافظه نگه میداره. و همه ی کوئری های بعدی روی این حافظه انجام میشه .
استفاده از DbContext مثل دستگاه های آب سردکن لحظه ایه. یک مخزن آب دارن که وقتی شما شیر رو باز میکنید آب رو در مسیر سرد میکنه. که فشار زیادی به دستگاه میاره و مصرف بالایی هم داره. اما ریپوزیتوری مثل اینه که بطری های آب رو درون یخچال نگه داری و هر وقت لازم داشتی یکی رو باز کنی و بخوری.
این یک اشتباه رایج در مورد نحوه ی کار DbContext و الگوی Repository هست. مارتین فاولر در کتاب Patterns of Enterprise Application Architecture که در تعریف الگوی Repository میگه :
A Repository mediates between the domain and data mapping layers, acting like an in-memory domain object
collection.
که مشخصا اشاره میکنه به اینکه Repository یک واسط بین Domain و Data Mapper هست که Domain همون مدلها و سرویسهاست و Data Mapper همون DbContext هست.
در واقع DbContext اطلاعات رو در حافظه ذخیره نمیکنه و برای اجرای هر عملیاتی به سراغ دیتابیس میره . اما Repository قراره داده هارو درون متغیرهای محلی ذخیره کنه که سرعت دسترسی به اونها بیشتر بشه. نقش Unit Of Work اینه که این حافظه ی موقت ایجاد شده رو زنده نگه داره و جلوی ازبین رفتنش رو بگیره تا بشه همیشه خیلی سریع به داده ها دسترسی داشت.
خروجی متدهای DbContext از نوع IQueryable هست. که در واقع یک کوئری هست و نه خود داده ها. یعنی داده ها قبل از اجرای متد وجود ندارن و در لحظه ای که خط داره اجرا میشه از دیتابیس جمع آوری میشن.
ولی در Repository از IList استفاده میشه. که نوع خاصی از آرایه هست که اطلاعات رو در حافظه نگه میداره. و همه ی کوئری های بعدی روی این حافظه انجام میشه .
استفاده از DbContext مثل دستگاه های آب سردکن لحظه ایه. یک مخزن آب دارن که وقتی شما شیر رو باز میکنید آب رو در مسیر سرد میکنه. که فشار زیادی به دستگاه میاره و مصرف بالایی هم داره. اما ریپوزیتوری مثل اینه که بطری های آب رو درون یخچال نگه داری و هر وقت لازم داشتی یکی رو باز کنی و بخوری.