چگونگی مدریت تنظیمات و Option های برنامه !!؟

[مهران رسا]

سلام،

یک نرم افزار بسیار بزرگ رو در نظر بگیرید که دارای تعداد زیادی Option برای هر قسمت هست . که ممکنه هر کدو از این Option ها دارای تعداد زیادی Sub-Option باشند و نهایتاً در زمان بسته شدن برنامه این تنظیمات رو برای استفاده های بعدی در Db ذخیره میکنیم .

حالا سوال اینجاست که در زمان بارگزاری مجدد نرم افزار چطوری با کم ترین میزان کد نویسی و اصولی ترین روش این حجم از تنظیمات و Option هارو مدیریت کنیم بطوری که در هرجای برنامه به راحتی قابل دسترس باشند ؟




Visual Studio Options > Main menu options > Top menu . position = 100
Visual Studio Options > Main menu options > Bottom menu . position = 800

[vcldeveloper]

برای همچین کارهایی میشه کلاس هایی تعریف کرد که تنظیمات مربوطه را بشه در داخل شی هایی از اون کلاس ها در برنامه نگه داری کرد. برای نگهداری داده های موجود در اون اشیاء، میشه از Serialization استفاده کرد، و داده های موجود در اشیاء را به فرمت دلخواه (مثلا XML یا بانک های اطلاعاتی، و غیره) تبدیل کرد. برای Serialization، یک راه این هست که یک کلاس مخصوص همون داده های برنامه نوشته بشه، که کارش لود کرد و ذخیره کردن داده های کلاس مربوطه به یک فرمت خاص باشه. یک راه دیگه اینه که کتابخانه Serializationایی داشت که بتونه هر شی ایی رو بگیره، و اون رو به فرمت خاصی Serialize کنه. یک نمونه از این Serialization رو درباره کامپوننت ها و فرم های دلفی می بینید، به این صورت که IDE کل فرم و کامپوننت های آن را در یک فایل DFM ذخیره میکنه، و میتونه از همون فایل هم مجددا فرم و کامپوننت های آن را بسازه. برای این منظور، کلاس های TStream دلفی متدهای خاصی برای Serialize کردن کامپوننت ها و کلاس های مشتق شده از TPersistent دارند. البته این روش فقط خصوصیات published رو ذخیره میکنه.

در دلفی یک کتابخانه Serialization استاندارد که همه چیز رو بتونه Serialize کنه، وجود نداره. البته در دلفی 2010 برای پشتیبانی از DataSnap، امکان Serialize کردن اشیاء به صورت JSON وجود داره. خودِ دلفی از این برای انتقال اشیاء از کلاینت به سرور و بالعکس در برنامه های DataSnap استفاده میکنه. از طرف دیگه، قابلیت Extended RTTI و همچنین قابلیت Attributes که در دلفی 2010 اضافه شدند، این امکان رو فراهم می کنند که بشه کتابخانه های جامعی برای Serialize کردن اشیاء به فرمت های مختلف، و همچنین برای ORM نوشت. بر همین اساس، کتابخانه هایی مثل DeHL (http://alex.ciobanu.org/) که برای دلفی نوشته شدند، قابلیت هایی برای Serialize کردن اشیاء به صورت XML، INI، و Binary و ذخیره در فایل، و لود کردن از فایل دارند.

البته کتابخانه هایی مثل hcOPF (http://www.tpersistent.com/?page_id=44) هم وجود دارند که تمرکز اصلی شان روی بانک اطلاعاتی هست، و قبل از پیدایش دلفی 2010 وجود داشتند.

[Felony]

کلاس TFileStream متدهایی با نام WriteComponentRes و ReadComponentRes در اختیارتون میزاره ، حدود 2 سال پیش دنبال این موضوع تو سایت های زبان اصلی بودم که به این موضوع برخورد کردم که دلفی از همین متد برای ذخیره تنضیمات استفاده میکنه و دنبالش رو گرفتم و به کمک برادر کشاورز این کد رو نوشتم که به راحتی میتونید تمامی تنضیمات برنامه رو با ساده ترین راه ذخیره کنید .

[مهران رسا]

البته منظور صرفاً ذخیره سازی خصوصیات اجزای فرم نیست . کلاً هر مشخصه ای که بخوایم در زمان اجرا بدون دردسر بهش دسترسی داشته باشیم :
مثلاً لیست محصولات یا اطلاعات کاربران (که مثلاً برای بررسی اطلاعات لاگین کاربران هر بار نیاز نباشه به Db مراجعه کنیم) . که فکر میکنم استفاده از کلاس راه خوبی باشه .

[مصطفی ساتکی]

برای بررسی اطلاعات لاگین کاربران هر بار نیاز نباشه به Db مراجعه کنیم
بهترین راه همونه که از db استفاده کنید .آخه کلاس هم بخاید بنویسید خیلی تمیز کار کنید میخاید یه چیزی مثل tdataset بنویسید این چه کاریه.

مثلاً لیست محصولات یا اطلاعات کاربران
این همه اطلاعات همیشه تو ram باشه واسه چه performance پس چی میشه

[tdkhakpur]

این همه اطلاعات همیشه تو ram باشه واسه چه performance پس چی میشه
به نظرم این عمل را برای دسترسی سریع در داخل تمامی فرمها برنامه احتیاج دارد.


برای بررسی اطلاعات لاگین کاربران هر بار نیاز نباشه به Db مراجعه کنیم

علاوه بر مطالب بالا همچنین میتوانید فضا را توسط CreateFileMapping دریافت و داده هایتان را در این فضا با دسترسی از طریق اسم فضای رزرو شده در دسترس داشته باشید.

[مهران رسا]

بله درسته . همه این کارها برای اینه که تا جای ممکن تبادل اطلاعات بین دیسک و برنامه(که خودش یکی از عوامل کاهش سرعت هست) به حداقل برسه .


بهترین راه همونه که از db استفاده کنید .آخه کلاس هم بخاید بنویسید خیلی تمیز کار کنید میخاید یه چیزی مثل tdataset بنویسید این چه کاریه. این همه اطلاعات همیشه تو ram باشه واسه چه performance پس چی میشه شما چه راه دیگه ای جز ارتباط مستقیم با Db پیشنهاد میکنید ؟

[vcldeveloper]

بهترین راه همونه که از db استفاده کنید .آخه کلاس هم بخاید بنویسید خیلی تمیز کار کنید میخاید یه چیزی مثل tdataset بنویسید این چه کاریه.
این چیزی که برای این منظور نوشته میشه، TDataset نیست، و شباهتی هم به آن نداره؛ به همچین سیستم هایی ORM (http://en.wikipedia.org/wiki/Object-relational_mapping) گفته میشه، و هدف از آنها این هست که به داده های بانک اطلاعاتی بدون توجه به ساختار واقعی داده ها در بانک اطلاعاتی، و نوع بانک اطلاعاتی، به شکل شی گرا دسترسی داشت، و بشه به راحتی آنها را به کنترل های رابط کاربر Map کرد. این کار مزیت های مختلفی داره، بخصوص در نرم افزارهای Enterprise. برای دلفی دات نت قبلا ECO وجود داشت که این کار رو انجام می داد. در دات نت الان مایکروسافت یک ORM قوی با نام Entity Framework (http://en.wikipedia.org/wiki/ADO.NET_Entity_Framework) ارائه میکنه.

[مصطفی ساتکی]

این چیزی که برای این منظور نوشته میشه، TDataset نیست، و شباهتی هم به آن نداره؛ به همچین سیستم هایی ORM (http://en.wikipedia.org/wiki/Object-relational_mapping) گفته میشه، و هدف از آنها این هست که به داده های بانک اطلاعاتی بدون توجه به ساختار واقعی داده ها در بانک اطلاعاتی، و نوع بانک اطلاعاتی، به شکل شی گرا دسترسی داشت، و بشه به راحتی آنها را به کنترل های رابط کاربر Map کرد.
من برای یه پروژه شبیه سازی همچین چیزی رو پیاده کردم آخرش قابلیت های یه tdataset تو داشت.vBulletin داره به همین روش عمل می کنه.بدون ساختار واقعی یعنی چی .بالاخره داده ها نوعش شون که مشخصه.میشه مثله یه database شخصی با یه خورده امکانات دلخواه.

[vcldeveloper]

بدون ساختار واقعی یعنی چی .بالاخره داده ها نوعش شون که مشخصه.بدون ساختار واقعی بانک اطلاعاتی، یعنی این لایه ORM خودش یک Abstraction ایجاد میکنه، و لایه های بالاتر که روی آن سوار هستند، لزوما با داده هایی که ساختار واقعی بانک اطلاعاتی زیرین را مشخص میکنه، کار نمی کنند؛ مثلا شما ممکن هست از طریق لایه ORM خودتان یک موجودیت تعریف کنید، که سایر لایه ها با آن به عنوان یک موجودیت واحد کار می کنند، اما در سطح بانک اطلاعاتی همان موجودیت فرضی در چند جدول پیاده سازی شده باشه. لزوما اینطور نیست که هر کلاسی که از ORM بیرون میاد، عینا متناظر یک موجودیت در بانک اطلاعاتی باشه. در دلفی کلاس TDataset یک لایه Abstraction بوجود میاره، ولی یک ORM قوی و کامل نیست، و در خیلی چیزها کمبود داره، برای همین هم کتابخانه های ORM مستقلی برای دلفی توسط افراد یا شرکت های ثالث نوشته شدند. برای نمونه می تونید به این پست Nick Hodeges مدیر تولید دلفی، رجوع کنید، که در آن بعضی از کتابخانه های ORM موجود برای دلفی را در جواب سوال کاربری ذکر کرده:
http://stackoverflow.com/questions/422426/orm-for-delphi-win32

البته غیر از اینها، کتابخانه های جدیدتری هم هستند که بر قابلیت های جدید دلفی 2010 اتکا دارند، و فقط هم روی ORM متمرکز نیستند، مثل DeHL (اصلا ORM نداره، فقط Serialization داره)، و Spring Framework که مدیر تیمش قبلا یک چینی بود (الان خبر ندارم)، و قرار بود به کتابخانه خودشان یک ORM مبتنی بر قابلیت های Extended RTTI اضافه کنند. در سایر زبان های برنامه نویسی مثل جاوا، یا سکوی برنامه نویسی دات نت هم کتابخانه هایی برای این منظور وجود داره، برای دات نت قبلا به Entity Framework اشاره کردم، که توسط مایکروسافت توسعه داده میشه NHibernate هم هست که اوپن سورس هست و بر اساس کتابخانه ORM معروف جاوا، با نام Hibernate ایجاد شده.

[مصطفی ساتکی]

راستی Rem Object یه همچین چیزی نداره(ORM) وقتی یه Object تعریف می کنی بتونی یه جورایی map بشه رو database و بتونی property های Object تت متصل کنی به interface باشه. من هر روز در حال کامپوننت تولید کردنم این موضوع رو شدیداً بهش نیاز پیدا کردم .ما یه همچین چیزی برای Delphi نداریم

[vcldeveloper]

راستی Rem Object یه همچین چیزی نداره(ORM) وقتی یه Object تعریف می کنی بتونی یه جورایی map بشه رو database و بتونی property های Object تت متصل کنی به interface باشه.
RemObjects یک محصول به نام DataAbstract داره، که ابزاری برای تولید لایه میانی در نرم افزارهای بانک های اطلاعاتی هست. خودِ DataAbstract این امکان رو داره که بشه از روی ساختار لایه های زیرین بانک اطلاعاتی، یک ساختار جدید برای لایه های بالاتر تولید کنه، ولی تا جایی که خاطر هم هست، یک ORM نیست، و داده رسیده به لایه های بالایی هم نوعی دیتاست هست. البته از اونجایی که بر اساس RemObjects SDK هست، میشه سمت سرور کلاس هایی برای کنترل دادهای بانک نوشت، و به جای ارائه دیتاست به لایه های بالاتر، همه کارها را از طریق این کلاس های سمت سرور پیاده سازی کرد.