نوشته شده توسط
hakim22
البته این کار در هیچ حالتی توجیه نداره ولی همانطور که دوستمون توضیح دادند یک روش برای ساخت جداول در زمان اجرا برنامه اینه که لیست فیلدها و نوع اونها را در یک جدول اولیه و از پیش ساخته ذخیره کنند و برنامه همیشه با رجوع به این جدول سایر جداول و فیلدهای درونشون رو پیدا میکنه.
میشه بجای اینکار با استفاده از چند حلقه و جستجو در میان collection های Columns و Rows در یک متغیر DataTable به راحتی هر نوع اطلاعاتی در مورد فیلدها بدست آورد.
صحبت توجیه نیست، این یک نیاز هست که باید بصورتی بالاخره هندل بشه؛ اکثراً هم در سیستمهای مختلف برای من نوعی پیش اومده و نشده که صورت مساله رو پاک کنیم! پس باید نسبت به نیاز سیستم، بین راهکارهای مختلف سوئیچ میکردیم (تو شرکتهای متفاوت برای دوستانی که میخوان بخندن!!!).
*********************************
صورت مسئله رو من میگم، تا براش راه حل پیدا کنیم:
مسئله: فرض کنید سیستمی داریم که کارفرما میخواد فیلدهای سفارشی براش داشته باشه (که کم هم نیستند)، مثلاً برای موجودیت مشتری: ما که همه چی رو نمی تونیم پیش بینی کنیم، یه روز میخواد شماره کفش مشتری رو اضافه کنه، یه روز رنگ مو، قد، سن، وزن، نام پسرعموی ناتنی و ...
یا در برنامه های حسابداری، انبارداری و فروشگاه، آیتمهای مختلف و جدیدی که بعنوان نیاز ضروری برای موجودیت های فاکتور، سند، انبار، کالا و ... پیش میان (تخفیف دوره ای، درصد متفاوت مالیات، جنس و ابعاد قاب تلویزیون! و الخ).
راهکاری که پیشنهاد میدین چی هست؟
راه حل ها: چیزایی که به ذهن آدم خطور میکنه:
- بیایم در جدول موجودیت (مثلاً مشتری) n تا فیلد خالی بذاریم، مثلاً field1, field2 , field3 , ... , fieldn و هرکدوم رو با توجه به نیاز به فیلد جدیدی (مثلاً فیلد درصد سلامتی) که درخواست مشتری هست اختصاص بدیم (خنده دار نیست! بعضی وقتا که فقط سرعت ملاک هست، شاید راهی جز این نداشته باشیم)
- تنها یک فیلد برای چنین نیازهایی درست کنیم و اون رو به یک سیستم خارجی ذخیره سازی وصل کنیم، مثلاً بگیم اطلاعات اضافی در یک فایل XML با این آدرس ذخیره شده و فقط آدرس فایل رو بذاریم تو اون فیلد (که اینکار هم مسلماً دنگ و فنگ های خودش رو داره، سیستم با فایل سیستم درگیر میشه و نگهداری و پیاده سازی نسبتاً پیچیده ای داره، معمولاً درگیر با refractor و ...)
- یه جدول CustomFieldValues برای مشتری ها درست کنیم، که شامل: Id مشتری، CustomFieldID و Value هست؛ CustomFieldID هم Id فیلد ما در یه جدول دیگه (بنام مثلاً CustomField) است که نام فیلد (مثلاً "شماره کفش مشتری") و نوع اون فیلد رو مشخص میکنه (مثلاً رشته، عدد، تاریخ و ...) که بعداً با نوع فیلد به مشکل نخورید. (این روش علیرغم زیبایی طراحی مشکل واکشی کند فیلدها و مقادیر و کوئری های پیچیده رو خواهد داشت و سرعت فدای طراحی صحیح میشه!)
- همون حالت قبلی با این تفاوت که تمام حالات ممکن نوع فیلد رو در جدول CustomFieldValues لحاظ کنیم، مثلاً یه فیلد برای رشته، یکی عدد، یکی تاریخ و اعشاری و ... (یکم سریعتر ولی باز هم طراحی برمیگرده مثل بند اول!)
- و در نهایت حالتی رو در نظر بگبرید که فقط برای یه موجودیت چنین قابلیتی نیاز نباشه، باید بتونیم Design pattern ای داشته باشیم که برای موجودیت های مختلف جوابگو باشه! تقریباً میشه یه فریمورک که Custom entity field رو باید باهاش پیاده سازی کرد؛ خوب فریمورک های آماده ای برای اینکار در زبانهای مختلف هست ولی اگه بخوایم خودمون پیاده اش کنیم، میشه با ترکیبی از دو بند قبل، چنین کاری کرد. مثلاً در جدول CustomField یه فیلد هم برای Entity ID داشته باشیم (مثلاً Id موجودیت مشتری -نه Id مشتری- یا Id موجودیت فاکتور، سند و فروشنده و ...) که بالطبع باید یه حدولی هم برای موجودیت ها درست کنیم و ...
*************
برای اینکه به MVC هم بیربط نباشه، بعنوان نمونه ای که در MVC چنین چیزی لازم میشه، فرمهایی هستند که شما به کاربر اجازه میدین خودش فیلدهایی بسازه و سپس با استفاده از اون فیلدها مقادیر رو ورد کنه؛ برای اینکار شما نیاز به مدلهایی برای اینکار خواهید داشت که Custom Field رو پیاده سازی کنن، یه حالتی مدلهای زیر :
public class CustomFormModel
{
public string FormId { get; set; }
public string Label { get; set; }
public CustomFieldModel[] Fields { get; set; }
}
public class CustomFieldModel
{
public DataType DateType { get; set; } // System.ComponentModel.DataAnnotations
public string FormKey { get; set; }
public string Label { get; set; }
public object Value { get; set; }
}
public class CustomFieldModel<T> : CustomFieldModel
{
public new T Value { get; set; }
}
برای طراحی صحیح هم برای اینکار از Composite pattern استفاده میشه، مثلاً یک اینترفیس درست میکنن که موارد بالا رو پباده سازی کرده باشه و شما کلاسهای فرمهاتون رو از اون به ارث ببید : نمونه » اینجا
______________
مطالعه بیشتر: The Entity Design Pattern
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول