استفاده از فایل های BPL ؟

[AlirezaBahredar]

با سلام ......
در مورد LoadPackage در سایت چند مورد مطرح شده،اما مطالب یا کلیست یا دوستانی که سئوال کننده بودند نتایج حاصل از تلاششون را نگفتند که آیا موفق شده اند یا نه.
در سایت های دیگه هم موارد تا حدودی بیان شده من الجمله سایت خوب Delphi.about.com اما جامعیت نداره.
من 3 تا سئوال دارم که ممنون میشم دوستان خوب منو راهنمایی کنند:
1)پس از لود کردن یک فایل BPL در برنامه اصلی آیا ما مستقیما می تونیم به کلیه اشیاء موجود در اون فایل BPL دسترسی داشته باشیم؟اگه جواب مثبت هست چگونه؟(من می خوام بدون تعریف تابع امکان دسترسی به اشیاء رو داشته باشم.اشیائی چون Button -Memo وغیره)
2)با فرض درست بودن مورد اول فرضا اگه من بخوام به یک dbGrid موجود در فایل BPL ای که از طریق فرم اصلی درون آن این فایل لود شده دیتا ها را به این dbGrid ارسال کنم آیا تا زمانی که من Connection ام را نبسته ام ارتباط برقرار است.
3)امکان داره که من بتونم از طریق لود کردن دو فایل BPL اطلاعاتی را از یکی به فایل BPL دیگری منتقل کنم؟اگه جواب مثبت هست چگونه؟
با تشکر.

[pad_kay]

با سلام
به این مقاله مراجعه کنید http://barnamenevis.org/forum/showthread.php?t=30800
تا حدودی در مورد روش کار در اون توضیح داده شده است
در مورد سوال دوم باید بگویم بله ولی نا با روش های معمول
موفق باشید

[vcldeveloper]

Dynamically Load Components From Packages at Run-Time (http://gethelp.devx.com/techtips/delphi_pro/10min/10min0301-1.asp)

Dynamic packages in Delphi (http://dn.codegear.com/print/27178)

[pad_kay]

Dynamically Load Components From Packages at Run-Time (http://gethelp.devx.com/techtips/delphi_pro/10min/10min0301-1.asp)

Dynamic packages in Delphi (http://dn.codegear.com/print/27178)


با سلام و خسته نباشید
من سایت ها و همچنین مقاله شما رو به صورت کامل مطالعه نمودم
در مورد سایت اول و مثالی که در آن ذکر شده لازم دیدم چند توضیح بدهم
1- در برنامه های بزرگ کارایی ندارد
2- غیر قابل اعتماد است
ولی با مطالعه مقاله روشی اتخاذ نمودم که هم در برنامه های بزرگ قابل اعتماد است هم کارایی آن بسیار بالا است

[hedi]

با سلام به دوست گرامی
فایل های اجرایی نرم افزار ها که همان EXE باشد برای تقسیم کار و اجرای سریعتر برنامه و همچنین کاهش فایل اجرایی از یکسری فایل های خارجی یا جانبی استفاده می کند که بنابر سلیقه برنامه نویس برنامه نوع آن متفاوت است اما در دلفی فایل های جانبی یا همان Application Extension ها به دوصورت معمول DLL یا BPL می باشد. فرق عمده DLL با BPL این است که :
زمانی که یک بخشی از نرم افزار خود را که حاوی فرم یا هر چیز دیگری است را تبدیل به DLL می کنید معمولا از نظر اندازه حجم بالایی دارند به طور مثال اگر یک بخش از نرم افزار را که تنها حاوی یک فرم است را به DLL تبدیل کنید حجمی در حدود 1 مگابایت را اشغال می کند و این در حالی است که در مقابل همان بخش را که حاوی یک فرم است را اگر به BPL تبدیل کنید حجمی در حدود 30 کیلوبایت را اشغال می کند.این تفاوت حجم به خاطر این امر است که در DLL به صورت Default اگر عمل کرده باشد Runtime Package ها مثل rtl100.bpl و ... ضمیمه فایل شده و حجم آن را بالا می برد و شما در کامپیوتر دیگری که فاقد این فایل هم باشد می توانید از این Dll بهره بگیرید اما اگر از BPL استفاده کرده باشید حتما باید فایل های Runtime Packeage ها را به همراه برنامه خود داشته باشید به نوعی باید برای برنامه خود Setup تهیه کنید بنابر این مسئله فایل های BPL به دلیل عدم ضمیمه کردن فایل های راه انداز حجم پایینی دارند.

خوب در مورد سه سوالی که پرسیدی :
1-اگر منظور از دسترسی به اشیا از فرم اصلی به فرم برنامه ای است که از طریق BPL باز شده ، منظور شما می باشد باید بگویم این کار نشد ندارد اما خیلی انجامش احتیاج به کدنویسی زیادی برای هر شی دارد و اصلا به زحمتش نمی ارزد.
2-در مورد سوال دوم باید بگویم بله اما باز این در صورتی است که اول از طریق فرم اصلی به Connection وجود در فرم BPL ای خود دسترسی پیدا کنید و آن را یک با True و False کنید و بعد کار مورد نظر را انجام بدهید در واقع این طئری می توانید Handle آن Connection را از طریق فرم اصلی در دست بگیرید .

3-در مورد سوال سوم هم پاسخ قطعی ندارم چون خودم باید روی این مسئله کار کنم

در کل به نظر من برای پروژه هایی که حجم آن ها از نظر سیستماتیک مناسب است استفاده از DLL معقول تر است اما اگر سیستمی خیلی بزرگ است و امکان دارد که استفاده از Dll کار را کند کند بدلیل حجمش BPL آخرین راه است.
من استفاده از DLL را بیشتر از BPL ترجیج میدهم

[vcldeveloper]

فایل های اجرایی نرم افزار ها که همان EXE باشد برای تقسیم کار و اجرای سریعتر برنامه و همچنین کاهش فایل اجرایی از یکسری فایل های خارجی یا جانبی استفاده می کند که بنابر سلیقه برنامه نویس برنامه نوع آن متفاوت است اما در دلفی فایل های جانبی یا همان Application Extension ها به دوصورت معمول DLL یا BPL می باشد.
استفاده از DLL یا BPL به خودی خود تاثیری در صورت برنامه نداره. هدف از ساخت برنامه بوسیله DLL یا BPL در وهله اول Modular کردن برنامه هست. این مسئله باعث میشه که تغییر در برنامه و Customize کردن آن برای شرایط یا مشتریان مختلف راحتتر باشه. در وهله دوم هم استفاده اشتراکی از منابع موجود هست، مثلا سرویس هایی که سیستم عامل ارائه میده، قابل Map شدن در فضای همه Processها هستند، پس عملا یک بار لود میشند، و توسط چندین Process استفاده میشند، بجای اینکه هر Process کپی مخصوص به خود را داشته باشه.


زمانی که یک بخشی از نرم افزار خود را که حاوی فرم یا هر چیز دیگری است را تبدیل به DLL می کنید معمولا از نظر اندازه حجم بالایی دارند به طور مثال اگر یک بخش از نرم افزار را که تنها حاوی یک فرم است را به DLL تبدیل کنید حجمی در حدود 1 مگابایت را اشغال می کند و این در حالی است که در مقابل همان بخش را که حاوی یک فرم است را اگر به BPL تبدیل کنید حجمی در حدود 30 کیلوبایت را اشغال می کند.این تفاوت حجم به خاطر این امر است که در DLL به صورت Default اگر عمل کرده باشد Runtime Package ها مثل rtl100.bpl و ... ضمیمه فایل شده و حجم آن را بالا می برد و شما در کامپیوتر دیگری که فاقد این فایل هم باشد می توانید از این Dll بهره بگیرید اما اگر از BPL استفاده کرده باشید حتما باید فایل های Runtime Packeage ها را به همراه برنامه خود داشته باشید به نوعی باید برای برنامه خود Setup تهیه کنید بنابر این مسئله فایل های BPL به دلیل عدم ضمیمه کردن فایل های راه انداز حجم پایینی دارند.
این به منزله کم حجم بودن فایل BPL نیست. اولا نه در DLL، و نه در BPL برنامه نویس مجبور نیست حتما از Packageهای Runtime مختلف در برنامه اش استفاده کنه. مثلا یک DLL میتونه فرم داشته باشه، ولی نه با اضافه کردن یونیت های Classes و Forms دلفی، بلکه فرضا با استفاده از توابع API، در این صورت نیازی هم نیست که کدهای Runtime Packageهای مختلف در آن موجب افزایش حجمش بشه.
اما نکته ایی که هست اینه که؛ حجم یک DLL حتی در صورت استفاده از Runtime Package مساوی هست با کد کاپایل شده DLL +کد کامپایل شده قسمت هایی از هر Runtime Packageایی که استفاده شده، یعنی اگر از یک Package فقط یک خط کد استفاده شده باشه، همون یک خط به پروژه لینک میشه، نه کل Package. اما برای BPL مساوی هست با حجم کد کامپایل شده آن BPL + کل اندازه فایل های Runtime Package ایی که اون BPL نیاز داره، یعنی اگر یک Package فرضا 3 مگ باشه، و فقط از یک خطش هم استفاده شده باشه، کل اون 3 مگ رو باید Deploy کنید.

تفاوت اصلی BPL و DLL در سایز فایل کامپایل شده آنها نیست، بلکه در قابلیت های آنها ست. DLL در ویندوز نوعی یک رابط بین زبان های برنامه نویسی مختلف هست، پس همیشه باید در استفاده از آن دقت کرد که نوع داده ها و قابلیت های ارائه شده به گونه ایی باشد که قابل استفاده در زبان های مختلف برنامه نویسی باشد، از طرفی رابط ارائه شده توسط DLL مبتنی بر تابع هست.
اما BPL هر چند خودش نوعی DLL محسوب میشود، ولی صرفا برای دلفی و C++ Builder طراحی شده، پس محدودیت های دست و پا گیر DLL را ندارد، از طرفی رابط ارائه شده در آن بر مبنای کلاس هست؛ رابط OOP ارائه می کند.
مشابه همین قابلیت را در ویندوز در محدوده ایی گسترده تر، در تکنولوژی COM می بینیم که یک رابط شی گرای مستقل از زبان برنامه نویسی مبتنی بر سیستم عامل ویندوز ارائه میکنه.

کار کردن با BPL مشکل تر و پیچیده تر از DLL هست، بخصوص که Documentation کافی هم برای آن وجود ندارد. ولی از نظر قابلیت، بسیار گسترده عمل میکنه، مثلا همین IDE دلفی برپایه BPL هست، یعنی تقریبا تمامی قابلیت هایی که بصورت گزینه های منو، ابزارها، یا کامپوننت های دلفی در IDE برای استفاده برنامه نویس ارائه میشوند، BPL هستند. در ایران هم بعضی شرکت ها از BPL استفاده های مفیدی برای افزودن قابلیت های مختلف بصورت Modular به نرم افزارهایشان کردند؛ یعنی بخش های مختلف یک محصول کاملا در BPLهای جداگانه طراحی و ساخته میشند، و بنا بر نیاز مشتری و نوع خدمات درخواستی وی، BPLهای مربوط به آن سرویس را به همراه برنامه مادر تحویل مشتری میشند - در واقع نوعی Framework برای plug-in.
پس اگر قرار هست از ماجول شما فقط برنامه دلفی استفاده کنه، و از طرفی نوع امکاناتی که این ماجول ارائه میکنه فراتر از چند تابع هست، اولویت با BPL هست، البته باید خودتان روش وقت زیادی بزارید و خیلی از قلق های آن را با سعی و خطا بدست بیارید. دو لینکی که در بالا گذاشتم مدخل خوبی برای ورود به این مبحث هستند.

موفق باشید

[AlirezaBahredar]

با سلام...
علی آقا ممنون از توضیخات کامل و جامعی که دادی. الحق و الانصاف حق مطلب را عالی اداکردی.از دوست خوبم Hedi هم ممنون بابت اظهار نظرشون.....
اما شاید درست بود من از ابتدا موضوع را اینطور بیان می کردم.
برنامه ای 1 سال پیش نوشته شد که به دلیل ماهیتش در نقاط دور دست و در تعداد زیاد نصب گردید.در همون اوایل پروژه احساس کردم که بایستی برنامه را بگونه ای بنویسم که قابلیت بروزرسانی را براحتی داشته باشه.با بررسی های صورت گرفته به دو مقوله DLL و BPL رسیدم.اما همونجوری که آقای کشاورز گفتند منابع مناسب و عملی برای این دو موضوع پیدا نکردم و به همین دلیل از استفاده کردن از این دو روش منصرف شدم و رو به روش سنتی یک برنامه Updater آوردم.
اما با گذشت 1 سال از اون جریان دوباره پروژه ای مطرح شده که باز به همین روش احتیاج دارد.
قبل از شروع کار می خواستم از چندین موضوع که در پست اول دادم مطمئن بشم.شاید مهمتر از اونا این سئوال باشه که
" بنظر استاتید محترم و دوستان خوبی که در این زمینه کار کردند و تجربه دارند برای مقوله بروزرسانی با توجه به فرمایشات دوستان و سختی برنامه نویسی به روش Dynamic DLL و استفاده از BPL و البته محدودیت های موجود در این دو روش و زمانبر بودن این روشها (بر طبق گفته دوستان که بایستی با روش سعی و خطا همراه باشد) آیا توجیه دارد که سراغ این روشها برویم یا خیر؟"
باز هم از اظهار نظرات دوستان پیشاپیش ممنونم.

[حمیدرضاصادقیان]

سلام.یک سوال هم من دارم. وقتی ما گزینه های مختلف رو در داخل bpl قرار می دهیم، اگر اون فایل رو طرف از جای دیگه ای بتونه گیر بیاره قاعدتا اون امکاناتی که در اون فایل هست برای طرف باز میشه.ایا راهی برای جلوگیری از این موضوع هست؟

[vcldeveloper]

وقتی ما گزینه های مختلف رو در داخل bpl قرار می دهیم، اگر اون فایل رو طرف از جای دیگه ای بتونه گیر بیاره قاعدتا اون امکاناتی که در اون فایل هست برای طرف باز میشه.ایا راهی برای جلوگیری از این موضوع هست؟
اگر هم به فرض فایل BPL توسط فرد دیگری مورد استفاده قرار بگیره، در وهله اول اون فرد باید یک SDK یا راهنمایی برای چگونکی کار با کلاس ها و توابع موجود در آن در اختیار داشته باشه، یا خودش سعی کنه با سعی و خطا و مهندسی معکوس به چگونگی کارکرد این کلاس ها و توابع پی ببره. از طرفی میشه برای این کتابخانه ها هم مثل هر برنامه دیگه ایی کدهایی برای حفاظت نوشت. مثل کامپوننت هایی که بررسی می کنند تا فقط در صورت وجود یک لایسنس خاص کامپوننت کار کنه، یا کامپوننت هایی که فقط در محدوده زمانی خاصی کار می کنند، و... این شما هستید که تصمیم می گیرید چطور باید از کتابخانه شما استفاده بشه، ممکن هست شما از برنامه نویسی که که کتابخانه شما را خریداری کرده بخواید که برای فراخوانی هر تابع، یک کد رجیستر که قبلا بهش داده اید را به کتابخانه ارسال کنه، تا افرادی که آن کد را ندارند، نتوانند از توابع به نفع خودشان استفاده کنند، یا هر راه دیگه ایی که ممکن هست به ذهنتان برسد.


قبل از شروع کار می خواستم از چندین موضوع که در پست اول دادم مطمئن بشم.شاید مهمتر از اونا این سئوال باشه که
" بنظر استاتید محترم و دوستان خوبی که در این زمینه کار کردند و تجربه دارند برای مقوله بروزرسانی با توجه به فرمایشات دوستان و سختی برنامه نویسی به روش Dynamic DLL و استفاده از BPL و البته محدودیت های موجود در این دو روش و زمانبر بودن این روشها (بر طبق گفته دوستان که بایستی با روش سعی و خطا همراه باشد) آیا توجیه دارد که سراغ این روشها برویم یا خیر؟"
بله، توجیح داره.
برای آپدیت برنامه خودتون سه راه کلی دارید:
1- استفاده از Binary Patch:
در این روش یک فایل Patch ساخته میشه که حاوی کلیه تغییرات در دو نسخه از یک فایل EXE هست؛ یعنی نسخه ایی از فایل EXE که کاربر دارد، و نسخه ایی از فایل EXE که بروز شده، با هم مقایسه میشوند، و یک فایل باینری حاوی تغییرات دو نسخه ایجاد میشود. اگر کاربر این فایل Patch را روی EXE ایی که دارد، اجرا کند،این EXE برابر با EXE بروز شده می شود. برای این کار نرم افزارهای مستقلی وجود دارند، ولی بعضی برنامه های ساخت Setup مثل InstallAware هم از آن پشتیبانی می کنند.

2- بروز کردن فایل EXE و مجبور کردن کاربر به دانلود کل فایل EXE برای بروز کردن نرم افزار. این بدترین حالت ممکن برای برنامه های بزرگ هست.

3- تقسیم بخش های مختلف برنامه به ماجول های کوچکتر، تا در زمان بروز رسانی کاربر فقط ماجول های بروزشده را دانلود کند، نه کل برنامه را. این روش را می توان با روش 1 هم ترکیب کرد، یعنی اگر حجم یا تعداد ماجول های بروز شده بزرگ هست، بجای ارسال کل فایل (ها) ، یک فایل Patch از آنها ساخته بشه که در سیستم کاربر تغییرات لازم را روی ماجول موردنظر اعمال کند. ویندوز از این روش برای بروزرسانی استفاده میکنه، یعنی کل ویندوز تشکیل شده از مجموعه بزرگی از ماجول ها که غالبا بصورت فایل های DLL هستند. فایل های Patch ویندوز تغییراتی در فایل باینری یک یا چند DLL بوجود میاورند.

مثلا اگر فرض کنیم شما نرم افزار را بوسیله CD روی سیستم کاربر نصب می کنید، و بعد با واسطه اینترنت آن را بروز می کنید، می توانید برنامه خود را با Runtime Packages کامپایل کنید. به این ترتیب BPL مربوط به کامپوننت های مختلفی که در برنامه استفاده کرده اید را به همراه برنامه نصب می کنید، این باعث کوچک شدن حجم فایل EXE می شود. هر زمان که نسخه جدیدی برای یکی از این کامپوننت ها منتشر شد، شما فقط BPL مربوط به آن را به کاربر ارسال می کنید. اگر هم فایل EXE شما تغییر کرد، فایل EXE خود را (بدون نیاز به BPLهایی که قبلا نصب شدند) ارسال می کنید. اگر لازم شد، می توانید حتی فایل EXE خود را به چند ماجول کوچکتر تقسیم کنید.
اگر چندین برنامه دلفی برای یک مشتری می نویسید هم استفاده از Runtime Packages ایده خوبی هست، چون در این صورت شما می توانید BPL مربوط به Packageهایی که بین همه این برنامه ها مشترک هستند را در هنگام نصب یکی از این برنامه ها درپوشه System32 نصب کنید، تا در هنگام نصب سایر برنامه های شما، نیازی به نصب مجدد اون BPLها نباشد، و فقط فایل EXE مربوطه، که حجم کمی هم دارد، نصب شود.
علت کوچک بودن فایل EXE برخی محیط های برنامه نویسی مثل ++Visual C هم همین هست. مایکروسافت چون خودش سازنده برنامه مربوطه و سیستم عامل مقصد هست، از قبل Runtime Packages مربوط به ++Visual C را در ویندوز نصب می کند، برای همین در اکثر مواقع برنامه های نوشته شده با این محیط نیازی به نصب Runtime Packages مربوطه ندارند، و فقط فایل EXE کم حجم مورد نظر را نصب می کنند.