سرمایه گذاری متفاوت در سال نو 🍎🌱 ۳۵٪ تخفیف نوروزی ➕ حضور رایگان در مسترمایند نخبگان صنعت نرم‌افزار 💻✅
۰ ثانیه
۰ دقیقه
۰ ساعت
۱ مرتضی زندیه
derived classes
جامعه مهندسی نرم افزار ایجاد شده در ۲۵ دی ۱۴۰۳

سلام

کلاس هایی به عنوان provider ایجاد کردیم مثل mongo و mysql و ... که با دیتابیس‌های مختلفی کار میکردن و اطلاعات یوزر رو چک میکردن

خب این کلاس‌های فقط UserProvider رو پیاده سازی کردن و ما فقط میتونیم کاربر رو روی دیتابیس‌های مختلف بسته به استراتژیمون مدیریت کنیم

در این صورت اگر بخوایم entity هایی به غیر کاربر رو هم provide کنیم، باز باید بیایم مثلا OrderProvider داشته باشیم و دیگر کلاس‌ها مثلا MySQLOrderProvider و ... رو پیاده سازی کنیم و MySQLOrderProvider رو به کنترلر پاس بدیم

که منطقی به نظر نمیرسه! درسته؟ در غیر این صورت باید چه کرد؟

سلام،

بهترین کار اینه که بجای اینکه برای هر مدل (مثل کاربر، سفارش و...) یک Provider مجزا درست کنیم، از یه ساختار منظم‌‌تر مثل Repository استفاده کنیم تا منطق دسترسی به دیتابیس توی لایه‌ جداگانه‌ای قرار بگیره. اینجوری هم کد تمیزتر میشه، هم به کنترلر و سرویس‌هامون کاری نداریم که دیتابیس کدومه یا چطوری باید کوئری زد. اگه ORM هم استفاده بشه که دیگه دردسر خیلی کمتر میشه و لازم نیست برای هر مدل یا دیتابیس یه Provider جدا تعریف کنیم.

نکته‌ی مهم اینه که کنترلر یا سرویس‌ها نباید مستقیماً به دیتابیس (MySQL/Mongo/...) وابسته باشن. اینها باید یک اینترفیس (یا کلاس انتزاعی) را بشناسن و منطق دیتابیس در ریپازیتوری/Provider یا لایه‌ی Data Access پنهان شود. اینطوری به‌ راحتی میتونی دیتابیسو عوض کنی یا تست‌های واحد بنویسی و سیستم‌ هم تمیزتر میمونه.

محسن موحد ۱۰ بهمن ۱۴۰۳، ۰۴:۴۰