برنامه نویسی چند لایه و شی گرا

[bad_boy_2007]

سلام دوستان من رشتم علوم کامپیوتر هست و درسی با موضوعات مرتبط با برنامه نویسی چند لایه نداشتم ولی با توجه به توضیحاتی که از دوستانی که در این انجمن و جاهای دیگه دادن فوضول شدم که یکم در این مورد اطلاعات کسب کنم حالا میخوام شما دوستای عزیز که مطلب دانشگاهی در این مورد پاس کردید عنوان و منبع درستون رو قید کنید و در صورت تمایل دانشگاهی که این مطلب رو تدریس میکنه و یا مطبی که غیر مرتبط به درس دانشگاه باشه ولی کاربردی و بدرد بخور باشه .

یکی دیگه در مورد برنامه نویسی شی گرا فکر کنم رشته مهندسی نرم افزار درسی با این عنوان داره ممنون میشم منبع تدریس این درس رو ذکر کنین و اگر کتاب مفیدی در این زمینه دارید معرفی کنید

[bad_boy_2007]

یکی جواب ما رو هم بده دیگه !

[teshneh]

سلام
بچه ها من مي خوام برنامه نويسي چند لايه (شي گرا) ياد بگيريم اگر منبعي داريد ممنون ميشم معرفي كنيد.
منظور pdf مفيد است.
با تشكر

[فاطـمه]

ببینید اینا به دردتون می خوره؟!

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

[teshneh]

سلام
دوست گرامي مطالبي كه شما معرفي كرديد بيشتر جنبه تئوريكي اين موضوع را پوشش داده بود، البته مفيد و لازم بود.
ولي من مثلا پروژه هاي كوچك مي خوام كه اين برنامه نويسي 3 لايه را گام به گام آموزش بده.
با تشكر

[teshneh]

سلام
دوست گرامي مطالبي كه شما معرفي كرديد بيشتر جنبه تئوريكي اين موضوع را پوشش داده بود، البته مفيد و لازم بود.
ولي من مثلا پروژه هاي كوچك مي خوام كه اين برنامه نويسي 3 لايه را گام به گام آموزش بده.
با تشكر

[MATRIX reloaded]

منم زیاد گشتم چیزی گیرم نیومد. چاره اینه که با آزمون خطا جلو بری

[_H2_]

سلام
مبحث شی گرایی کمی گستردگی دارد و با توجه به زبان برنامه نویسی باید روی کلمات کلیدی مرتبطتش بحث شود.

البته کلاً به نظر من جدا از این مباحث کلاً هر فردی باید در زبان برنامه نویسی خودش تمام کلمات کلیدی و رزو شده را بشناسد و تک تک را بداند که چه میکند و کجا کاربرد دارد.

با اموزش تمام کلمات کلیدی خود به خود مسئله یادگیری اصول شی گرایی هم حل میشود.
(تفکر محل صحیح استفاده در برنامه هم خودش به مرور مستحکم شده و جایش را باز میکند.)

مثلاً برای یادگیری شی گرایی در C#.Net باید تمام کاربرها و محل استفاده کلمات زیر را بلد باشید:

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

یا برنامه نویس VB.Net باید تمام کلمات زیر را برای پیاده سازی شی گرایی بلد و مسلط باشد:

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

متاسفانه متاسفانه متاسفانه جدیداً مد شده هر کسی دو تا کلمه کلیدی if و for و while یاد گرفت فکر میکند دیگر برنامه نویس شده و به بقیه کلمات کلیدی و امکانات کاری ندارد.

کتابهای قدیمی قبلاً ضمینه ای داشتند که کل کلمات کلیدی زبان مورد آموزش را لیست شده و مدون داشت.
حالا ماشا ا... قربانش بروم نویسنده هم نمی دانم تنبل شده اند بی وجدان تر شده اند یا نادان تر شده اند(!) ...
دیگر من در هیچ یک از کتوب مختلف زبانهای برنامه نویسی مختلف چاپ جدید اصلاً ندیدم که فهرست کلمات کلیدی را داشته باشد و یا نویسنده خودش را موظف بداند که تا اخر کتاب همه کلمات یاحداقل اکثریت انها را آموزش دهد.
(
یک دو تا دستور رسم خط و فوقش یک اتصال به دیتابیس را در کتابش یاد میدهد، خواننده کلی حال میکند که چه زود برنامه نویسی یاد گرفته، نویسنده کلی حال میکند که کتابش چه فروشی داشته، همه راضی و خوشحالند! فقط این وسط من باید حرسش را بخورم!
)


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

==============

و اما لایه بندی ...
بر خلاف شی گرایی اصلاً یک امکان و مبحث زبان برنامه نویسی نیست و هیچ کلمه کلیدی و پشتیبانی برای آن ندارم.
صرفاً یک تئوری است. البته یک تئوری و تفکر مفید.
شاید بیشترین پیشتیبانی از برنامه نویسی چند لایه آن باشد که زبان برنامه نویسی اجازه تولید بسته های کد قابل استفاده مجدد (مثلاً در قالب dll) را بدهد.

تئوریش هم خیلی خیلی ساده و روشن است.
اگر خودتان خودتان ار گیچ نکنید، هیچ جای سیاه و تاریک و نا مفهومی وجود ندارد.

مثلاً برنامه نویسی سه لایه یعنی چه؟

شما می آید و کدهای ارتباط با دیتابیس را کاملاً جدا و در یک محل مشخص (مثلا یک dll قرار میدهد)
این میشود لایه اول و دیتابیس.

یعنی به جای اینکه مثل ماکارونی درهم و ورهم (اسپاگنتی!) هر کجا رسیدید و نیاز بود الی ا... یک Connection به دیتابیس بسازید و دستور SQL ای اجرا کنید و نتیجه را بگیرید ...
دیگر از این کثیف کاری ها خبری نیست!
Connection دیتابیس و هر ارتباطی با ان فقط مختص لایه دیتابیس خواهد بود.

مثلاً کلاسی و متدی در این لایه (لایه دیتابیس) دارید (delete(int primarykey که در هر کجای کدها خواستید سطری از جدول خاصی را حذف کنید به جای آنها همانجا درهم و ورهم به دیتابیس وصل شوید این متد را صدا میزنید!

این کار سختی است؟
یک متد delete دارید که primarykey را میگیرد و سطر را حذف میکند، کافی است از نقاط دیگرش اجرایش کنید.

این یعنی برنامه نویسی لایه ای !!!!


یک لایه هم میشود همان فرم ها و پوسته مرتبط با کاربر که فقط اطلاعات را میگیرد و در TextBox و کنترلرها نمایش میدهد و یا اطلاعات انها را پس میدهد.
یک ورودی و خروجی .


یک لایه هم میشود لایه برنامه اصلی که کدهایی است که لایه نمایش را به لایه دیتابیس مرتبط کرده و فرآیندهای اصلی را در این بخش کد نویسی میکنید.

تمام شد!

برنامه را به بخش های مشخص میشکنید (مثل یک اداره یا مثل یک شی بزرگ مانند خودرو) و هر بخش فقط کار خودش را انجام میدهد و حق داشتن کدهای مرتبط با کار بخش های دیگر را ندارد.

(
همانطور که ضبط صوت یک ماشین جزئی از ماشین است ولی به تنهایی مستقل هم است.
قرار نیست مدارات و قطعات برف پاک کن ماشین نصفش در ضبط صوت ماشین جاسازی شده باشد!!!!
یا سیم های برف پاک کن از وسط پیستون ها رد شود!!!
)

==============

نمونه بدردبخوری نیست و ناقص است ولی شاید تفکر برنامه نویسی چند لایه را نشان دهد که چطور سنگ بنای یک برنامه را برای لایه بندی بگذارید:
support.h02.ir/fwlink/?LinkId=1000866237

تاپیک مرتبط البته تعطیل شده. (من بی تقصیرم! من بیچاره از اول گفتم وقت ندارم )
[ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ]

جمیعاً موفق باشید.

[bad_boy_2007]

ممنون استاد H2
من در مورد برنامه نويسي شي گرا مشكلي ندارم ، در مورد برنامه نويسي چند لايه هم در بخش تئوري اش مشكلي نيست ولي اينكه بصورت مفهومي كه بتوانم پياده سازي كنم درك لازمه را ندارم .
از اين نظر كه در هر فرم با فشردن كليد در رويداد كليد بيايم و Command و كانكشن ايجاد كنم ، قواعد را رعايت ميكنم ، پروژه ام را به 22 Dll مجزا تفكيك كرده ام و در هر DLL بسته به نوع داده هايي كه ذخيره ميشود طبق استاندارد مصوب خودمان ! چهار تابع را درنظر گرفته ايم :

ADD : كه يك استراكچر را ميگيرد و در جدول يا جداول مربوطه در ديتابيس ذخيره ميكند
Edit : كه يك استراكچر را ميگيرد و اصلاح ميكند از جمله مشخصه هاي اين استراكچر ID است كه به كليد ركوردي كه بايد اصلاح شود مرتبط ميشود
Delete : با دريافت كليد اقدام به حذف ركورد ميكند
GetInfo : كه يك كليد را ميگيرد و استراكچر را پس ميدهد

اين استاندارد شركت ما است ، حال نميدانم واقعا راهي بهتر از اين هست يا خير ؟ چونكه من در شركتهاي بزرگ و با افراد با تجربه كار نكرده ام و اين را هم به صرف تجربه 3 يا 4 سال برنامه نويسي پياده سازي كرده ام .

در تمام توابع فوق اشياء كامند و كانكشن وجود دارند كه رشته اتصال را از يك DLL به نام Setting دريافت ميكنند ، بصورت كلي تمام تنظيمات برنامه از نگ زمينه كليدها ، فاصله بين دو پشتيبان گيري اتومات ، تنظيمات قيمت و .... را از اين DLL ميگيريم ، حال اين تنظيمات ميخواهد در ديتابيس ذخيره شده باشد يا در Setting خود DLL .

آيا به اين شيوه كار ما ميشود برنامه نويسي چند لايه گفت ؟

مثلا ما DLL اي داريم به نام Customer حال اگر بخواهم نام مشتري اي با كد 25 را پيدا كنم :

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

به همين شكل اگر بخواهم مشتري اي با نام "Ali" را تعريف كنم :

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

و ...

برخي استراكچر را را كمي پيچيده تر گرفته ايم ، مثلا استراكچر فاكتور فروش ، از آرايه اي از استراكچر ها كه اين استراكچر ها هركدامشان يك سطر از اقلام فاكتور و يك سري فيلدهاي ثابت مثل تخفيف ، كرايه و ... و استراكچري كه خود ساختار مشابه استراكچر فاكتور را دارد (سند دريافت كه ميتواند آرايه اي از چكها ، مبالغ نقدي ، حواله ها و .. باشد) ساختار آن به شكل زير است :

نمونه اي C# :

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

نمونه اي VB :

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

و ...
سرتان را به درد آوردم ، ولي اين خلاصه اي از برنامه من بود . حال نميدانم آيا ميتوانم لفظ چند لايه را براي اين برنامه به كار ببرم ؟؟؟؟

[_H2_]

سلام

اين استاندارد شركت ما است ، حال نميدانم واقعا راهي بهتر از اين هست يا خير ؟

خوب است.
البته من معمولاً نام Delete و Select و Insert و Update را ترجیح میدهم!
و در خیلی از مواقع متد جدایی برای Insert هم نمیگذارم و متد Update خودکار اگر PrimaryKey پر باشد، اپدیت میکند وگرنه Insert میکند.
چون در نهایت هم دستور SQL مربوط به Update و Insert فرق دارد ولی (با عنایت به روش پارامتری) کد های داخلی زبان برنامه نویسشان تفاوت زیادی ندارد.

داشتن این چهار تابع خوب است ولی شاید لازم به یادآوری نباشد که، باید این لایه شما غنی باشد و بتواند با شرایط گونان کار کند و امکاناتش را داشته باشد تا سایر لایه ها مجبور به اتصال سرخود با بانک اصلی نشود.
منظورم ان است که شما تابعی با نام GetInfo دارید (یا نام Select !) ولی معمولاً این تابع باید بیش از یک Overload داشته باشد.
(
مثلاً اگر جدول کتاب دارید باید یک Overload کلید را بگیرد و اطلاعات کتاب را پس دهد و یک Overload دیگر کد نویسنده را بگیرد و لیست کتابها را بر گرداند و...)
)

البته شرکت های تولید کننده و پشتیبان یک زبان برنامه نویسی سعی کرده اند که امکاناتی در زبان برنامه نویسی و محیط قرار دهد که طراحی لایه دیتابیس را تا حد امکان و در حد چند کلیک ساده بکند.
مثلاً در C#.Net و VB.Net امکاناتی مثل تعریف TypedDataSet و یا EntityDataModel در نظر گرفته شده که به برنامه نویس اجازه میدهد با چند کلیک ساده و سریع لایه دیتابیس را تولید کند و خیلی راحت با ساختار دیتابیس رابطه ای مرجع و اصلی هماهنگ کند.

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

که در این میان برنامه نویس باید بین زمان تولید و قابلیت نگه داری و از طرف دیگر سرعت و بازدهی تعادلی ایجاد کند.

حال اين تنظيمات ميخواهد در ديتابيس ذخيره شده باشد يا در Setting خود DLL .

الکی یاد کارتونی افتادم !
بله البته، یکسری از تنظیمات مثل خود ConnectionString را نمیتوان در دیتابیس قرار داد.
(یاد کارتون لوک خوش شانس می اندازد که در قسمتی، برادران دالتون بانک تاسیس کرده بودند و کلید گاوصندوق را برای امنیت در خود گاوصندوق می گذاشتند، بعد مدام با دینامیت دربش را باز میکردند! )

نمونه اي VB

مثلاً باز کدی برای تابع CustomerFactorName نوشته اید که در داخل ساختار STRSellOrder قرار دارد.
اگر این عمل را هم در محل مجتمع شده (کنار ADD و Edit و Delete و GetInfo) انجام دهید شایسته تر است.
یعنی خود این ساختار که در لایه دیتابیس باشد، درست ولی باز هم اگر بتوانید دستورات و ارتباطات را از ساختار دیتاگرایی مثل همین که داشتید جدا کنید، بهتر است.

ضمن اینکه خود دستورات SQL هم میتواند یک لایه باشد.
برای موارد پر مصرف و مهم و جایی که سرعت مهم است (کلاً تا جایی که میتوانید) سعی کنید دستورات SQL را به داخل خود دیتابیس منتقل کنید و دستورات SQL را تا حد امکان از پراکندگی داخل کدها جمع کنید انها را مجتمع شده در SP ها و View ها و... دیتابیس مستقر کنید.

این هم خودش نوعی لایه بندی و تفکیک وظایف است.

اگر هم یک زمانی برای کار خیلی پیش پا افتاده ای دستور SQL را نیاز شد در خود کدها قرار دهید، حداقل سعی کنید این دستور در لایه DLL ای دیتابیس باشد و با یک دستور Const در بالا و اولین خطهای کدتان تعریف شود تا همه SQL ها در بالای فایل کد کنار هم مجتمع باشند و معلوم باشد این فایل کد داخلش حاوی دستورات مستقیم SQL است و اگر زمانی فیلدی را تغییر نام دادید و چیزی اضافه و کم کردید (در دوره های بعدی توصعه برنامه تان) راحت بتوانید تمام دستورات SQL را مجتمع شده در لایه DLL مشخص و اول سورس کدها پیدا کرده و در صورت نیاز اصلاح کنید.

(برای پارامترها هم که خیلی راحت میتوانید از روش پارامتاری برای هر نوعی استفاده کنید، فقط در دات نت حواستان به تغییر Null زبان با DBNull باشد)

حال نميدانم آيا ميتوانم لفظ چند لايه را براي اين برنامه به كار ببرم ؟؟؟؟
آيا به اين شيوه كار ما ميشود برنامه نويسي چند لايه گفت ؟

تا اینجا که شما تعریف کردید بله!
فقط کافی است یکم دقت بیشتری کنید و کدی را که میخواهید بنویسی یک لحظه کوتاه فکر کنید و ببینید در کدام لایه باشد بهتر خواهد بود.

=====

ضمناً حالا که حرفش شده باید ذکر کنم بجز مفاهیم شی گرایی و لایه بندی مفهوم بالاتری هم با نام سرویس گرایی هم داریم.
کلیه این مفاهیم در این جهت است که برنامه هایی را که مدام توصعه می یابند و حجیم و حجیم تر میشوند را در اختیار و کنترلر برنامه نویس نگه دارد و دید برنامه نویس گسترش یافته و بتواند به پهنای عظیم تری نگاه کند و فکر کند.
طبیعتاً از پیامدهای این تسلط و اشراف برنامه نویس به پروژه میتواند کاهش باگ و افزایش بازدهی و افزایش قابلیت نگهداری باشد.

اگر کد از دست برنامه نویس خارج شود (که یعنی قواعد کار را رعایت نکرده) و برنامه نویس گیج شود و در تو در توی Copy/Paste های آن چشمش سیاهی برود به طبع باگ ها افزایش می یابد و بازدهی کم شده و قابلیت نگه داری هم تا حد صقر مطلق سقوط خواهد کرد.

موفق و شاد باشید.