برنامه چندلایه چیست ؟
به نقل از : http://www.developercenter.ir/Forum/...ead.php?t=5939
در معماری چند لایه تمام برنامه به چندین بخش تقسیم میشود. این بخشها میتوانند Ùیزیکی یا منطقی باشند. هر بخش کار خاصی را انجام میدهد مثلا نمایش interface کاربر یا دسترسی به داده ها. برنامه Ù…ÛŒ تواند به هر تعداد لایه داشته باشد ولی به هر Øال بیشتر برنامه ها سه لایه ÛŒ مجزا دارند Ú©Ù‡ عبارت اند از:
Presentation Layer
Business Logic Layer
Data Access Layer
همان*طور Ú©Ù‡ اØتمالا Øدس زده*اید، لایه*ÛŒ Presentation چیزی نیست به جز بخشی از نرم*اÙزار Ú©Ù‡ با کاربر برنامه*ÛŒ شما ارتباط برقرار Ù…ÛŒ*کند (interface برنامه*ÛŒ شماست). نمایش داده*ها به کاربر نهایی Ùˆ اجازه به آنان برای ارتباط داشتن با داده*ها، اصلی*ترین وظیÙÙ‡*ÛŒ این لایه است.
در بیش*تر موارد، داده*هایی Ú©Ù‡ توسط کاربر وارد Ù…ÛŒ*شوند نیاز به اعتبارسنجی یا پردازش اضاÙÛŒ دارند. این مسؤولیت لایه*ÛŒ Business Logic است.
در نهایت داده*های برنامه*ÛŒ شما نیاز به ذخیره Ùˆ بازیابی از طریق یک انبار داده دارند (مثلا سیستم مدیریت DataBaseهای رابطه*ای یا RDBMS Ùˆ یا XML Ùˆ ...) این وظیÙÙ‡ توسط لایه*ÛŒ دسترسی به داده انجام Ù…ÛŒ*شود.
به*طور خلاصه، Ùرایند مورد نظر ما این*گونه کار Ù…ÛŒ*کند:
- کاربر برای داده*های برنامه، درخواستی ارسال می*کند.
- لایه*ÛŒ Data Access داده*های مورد نظر را بازیابی Ù…ÛŒ*کند Ùˆ از طریق لایه*ÛŒ Business Logic آن*ها را به لایه*ÛŒ نمایش Ù…ÛŒ*Ùرستد. بعضی مواقع لایه*ÛŒ دسترسی به داده*ها، این داده*ها را مستقیما به لایه*ÛŒ نمایش ارسال Ù…ÛŒ*کند.
- لایه*ÛŒ نمایش اطلاعاتی Ú©Ù‡ باید نمایش داده شوند را از طریق لایه*ÛŒ Business Logic دریاÙت Ù…ÛŒ*کند.
- کاربر داده*ها را تغییر Ù…ÛŒ*دهد Ùˆ عمل مناسب در مورد آن*ها را اجرا Ù…ÛŒ*کند (مثل اضاÙÙ‡ یا به*روز کردن داده*ها)
- لایه*ÛŒ Business Logic صØت داده*های وارد شده توسط کاربر را بررسی Ù…ÛŒ*کند (داده*ها را اعتبارسنجی Ù…ÛŒ*کند)
- اگر داده*ها معتبر باشند آن*ها را برای به*روز رسانی در بانک اطلاعاتی به*دست لایه*ی دسترسی به داده می*سپارد.
مزیت*های برنامه*های چند لایه
- برنامه*ها به چند بخش منطقی جدا از هم تقسیم می*شوند و اتصال میان UI (رابط کاربری)، پردازش*ها و بانک اطلاعاتی کم می*شود.
- تغییر در بانک اطلاعاتی یا روال*های دسترسی به داده*ها، تاثیری در لایه*ی نمایش یا برنامه*ی کلاینت نخواهد گذاشت.
- برنامه*ی کلاینت با عبارات SQL آمیخته نخواهد شد.
- نام جداول Ùˆ ستون*ها به*طور مؤثری از برنامه*ÛŒ Client ØØ°Ù Ù…ÛŒ*شوند.
- برنامه*ÛŒ Client نمی*Ùهمد Ú©Ù‡ داده*ها از کجا آمده*اند (چیزی Ú©Ù‡ به آن Location Transparency Ú¯Ùته Ù…ÛŒ*شود)
- تغییر یا گسترش برنامه بسیار ساده*تر خواهد شد، بدون نیاز به تغییر یا کامپایل مجدد برنامه*ی Client.
نکته*ÛŒ منÙÛŒ در معماری چند لایه این است Ú©Ù‡ شما باید تعداد زیادی بخش*ها Ùˆ کلاس*های ازهم جدا در نرم*اÙزار بسازید. اما به هر Øال مزایای این روش بیش*تر Ùˆ برتر از معایب آن است.
انتخاب*های لایه*ی Presentation
دو انتخاب اصلی برای ساخت یک لایه*ÛŒ نمایش در دات نت وجود دارد. آن*ها Ùرم*های ویندوزی یا Ùرم*های وبی ASP.NET هستند.
با استÙاده از ویندوز Ùرم*ها شما Ù…ÛŒ*توانید برنامه*های دسکتاپ Ùرم Ù…Øور (Form Base) معمول را بسازید. برنامه*های ویندوز Ùرمی Ù…ÛŒ*توانند المان*های رابط کاربری بسیار غنی به*کاربر پیشنهاد کنند. آن*ها Ú©Ù… Ùˆ بیش شبیه به Ùرم*های ویژوال بیسیک هستند.
جذاب*ترین گزینه برای توسعه*ÛŒ لایه*ÛŒ نمایش استÙاده از وب Ùرم*های ASP.NET است. کنترل*هایی مثل: دیتاگرید، دیتالیست Ùˆ تقویم (Calendar) یک رابط کاربری قدرتمند را با مقدار Ú©Ù…ÛŒ کد Ùراهم Ù…ÛŒ*کنند.
انتخاب*هایی Ú©Ù‡ در بالا برای ساخت یک لایه*ÛŒ نمایش بررسی کردیم Ù…ÛŒ*توانند توسط زبان*های مختلÙÛŒ مثل C#Visual Studio.Net پیاده*سازی شوند.
انتخاب*های لایه*ی Business Logic
لایه*ی Business Logic از چندین بخش که کارهایی نظیر اعتبار سنجی کار، گردش کار یا کارهای مشابه را انجام می*دهند تشکیل شده است.
Componentهای .Net این لایه را Ø´Ú©Ù„ Ù…ÛŒ*دهند. شما Ù…ÛŒ*توانید با Interop از Componentهای COM استÙاده کنید ولی این کار کارایی را پایین خواهد آورد.
وب*سرویس*های ASP.NET هم Ù…ÛŒ*توانند به*عنوان یک Business Logic عمل کنند. اما به هر Øال آن*ها را نمی*توان در همه*ÛŒ شرایط به*عنوان جایگزین Componentها به*کار برد. وب*سرویس*ها تنها زمانی قابل استÙاده خواهند بود Ú©Ù‡ اعتبارسنجی در جایی بیرون از شبکه*ÛŒ شما اتÙاق اÙتاده باشد.
Componentهایی Ú©Ù‡ توسعه Ù…ÛŒ*دهید به ماندن روی ماشین*های مشابه نیازی ندارند. با استÙاده از دات NET Remoting Ù…ÛŒ*توانید آن*ها را روی چندین ماشین توزیع کنید.
انتخاب*های لایه*ی Data Access
این لایه با دستکاری داده*ها مثل اضاÙه، ØØ°Ù Ùˆ به*روز رسانی آن*ها سر Ùˆ کار دارد. داده*هایی Ú©Ù‡ به آن*ها اشاره کردیم Ù…ÛŒ*توانند در RDBMS یا XML قرار داشته باشند. شما باید لایه*ÛŒ دسترسی به داده را چنان طراØÛŒ کنید Ú©Ù‡ دیگر لایه*ها نیازی به دانستن وضعیت انبار داده*ها نداشته باشند.
ADO.NET Ùناوری دسترسی به داده*ÛŒ تØت دات .Net است. اگر Ú†Ù‡ ADO.NET از طریق کلاس*های DataReader اجازه*ÛŒ دسترسی به داده*های در هنگام اتصال را Ù…ÛŒ*دهد ولی بیش*ترین تمرکز روی دسترسی به داده*ها در زمان متصل نبودن است. DataSet نقش کلیدی را در این مورد بازی Ù…ÛŒ*کند. در بعضی موارد Ù…ÛŒ*توانید ADO را هم برای دسترسی به داده*ها استÙاده کنید ولی استÙاده از آن باید دلیل معتبری داشته باشد. از ADO استÙاده نکنید Ùقط به خاطر این*Ú©Ù‡ RecordSetها را دوست دارید!
این*جا هم Componentهای .Net لایه را تشکیل Ù…ÛŒ*دهند. همان*طور Ú©Ù‡ قبلا Ú¯Ùته شد Ù…ÛŒ*توانید از Componentهای کلاسیک COM هم استÙاده کنید.
هم*چنین وب*سرویس*ها هم Ù…ÛŒ*توانند لایه*ÛŒ دسترسی به داده را Ø´Ú©Ù„ دهند. این مخصوصا زمانی درست است Ú©Ù‡ DataBase شما Ùراهم*کننده*ÛŒ (Provider) داده ندارد. در این*گونه موارد شما Ù…ÛŒ*توانید مقداری کد برای اتصال به داده*ها Ùˆ پر کردن DataBaseها Ùˆ بازگرداندن نتایج درون DataSet به درخواست*کننده*ÛŒ داده بنویسید.
علاوه بر ADO.NET شما Ù…ÛŒ*توانید از امکانات سیستم مدیریت DataBase خود مثل توابع Ùˆ یا روال*های ذخیره شده (Stored Procedures) استÙاده کنید.
ارسال داده از یک لایه به لایه*ی دیگر
در تمام موارد به ارسال اطلاعات از یک لایه به لایه*ÛŒ دیگر نیاز است؛ به*طور معمول برنامه*نویسان از رشته*ها، آرایه*ها، RecordSetهای غیرمتصل برای رسیدن به این هد٠استÙاده Ù…ÛŒ*کنند. در .Net ØŒ DataSetها یک راه Ùوق*العاده برای انتقال اطلاعات میان لایه*ها Ùراهم Ù…ÛŒ*کنند. شما Øتی Ù…ÛŒ*توانید با برنامه*نویسی یک DataSet بسازید Ùˆ آن را با داده*های خودتان پر کنید. اگر اشیا را خیلی دوست دارید Ù…ÛŒ*توانید از Typed DataSets استÙاده کنید Ú©Ù‡ در واقع کلاسی مشتق شده از کلاس DataSet است Ú©Ù‡ جداول Ùˆ سطرها را به Ø´Ú©Ù„ یک Ø´ÛŒ معرÙÛŒ Ù…ÛŒ*کند.
منبع :http://www.roshd.ir
پیوست » از وقتی این ممد ادیتور را انگولک کرده Ùاصله ها در متنهای Ú©Ù¾ÛŒ پیست شده * میخورن به منم هیچ ربطی نداره
به نقل از : http://www.developercenter.ir/Forum/...ead.php?t=5939
در معماری چند لایه تمام برنامه به چندین بخش تقسیم میشود. این بخشها میتوانند Ùیزیکی یا منطقی باشند. هر بخش کار خاصی را انجام میدهد مثلا نمایش interface کاربر یا دسترسی به داده ها. برنامه Ù…ÛŒ تواند به هر تعداد لایه داشته باشد ولی به هر Øال بیشتر برنامه ها سه لایه ÛŒ مجزا دارند Ú©Ù‡ عبارت اند از:
Presentation Layer
Business Logic Layer
Data Access Layer
همان*طور Ú©Ù‡ اØتمالا Øدس زده*اید، لایه*ÛŒ Presentation چیزی نیست به جز بخشی از نرم*اÙزار Ú©Ù‡ با کاربر برنامه*ÛŒ شما ارتباط برقرار Ù…ÛŒ*کند (interface برنامه*ÛŒ شماست). نمایش داده*ها به کاربر نهایی Ùˆ اجازه به آنان برای ارتباط داشتن با داده*ها، اصلی*ترین وظیÙÙ‡*ÛŒ این لایه است.
در بیش*تر موارد، داده*هایی Ú©Ù‡ توسط کاربر وارد Ù…ÛŒ*شوند نیاز به اعتبارسنجی یا پردازش اضاÙÛŒ دارند. این مسؤولیت لایه*ÛŒ Business Logic است.
در نهایت داده*های برنامه*ÛŒ شما نیاز به ذخیره Ùˆ بازیابی از طریق یک انبار داده دارند (مثلا سیستم مدیریت DataBaseهای رابطه*ای یا RDBMS Ùˆ یا XML Ùˆ ...) این وظیÙÙ‡ توسط لایه*ÛŒ دسترسی به داده انجام Ù…ÛŒ*شود.
به*طور خلاصه، Ùرایند مورد نظر ما این*گونه کار Ù…ÛŒ*کند:
- کاربر برای داده*های برنامه، درخواستی ارسال می*کند.
- لایه*ÛŒ Data Access داده*های مورد نظر را بازیابی Ù…ÛŒ*کند Ùˆ از طریق لایه*ÛŒ Business Logic آن*ها را به لایه*ÛŒ نمایش Ù…ÛŒ*Ùرستد. بعضی مواقع لایه*ÛŒ دسترسی به داده*ها، این داده*ها را مستقیما به لایه*ÛŒ نمایش ارسال Ù…ÛŒ*کند.
- لایه*ÛŒ نمایش اطلاعاتی Ú©Ù‡ باید نمایش داده شوند را از طریق لایه*ÛŒ Business Logic دریاÙت Ù…ÛŒ*کند.
- کاربر داده*ها را تغییر Ù…ÛŒ*دهد Ùˆ عمل مناسب در مورد آن*ها را اجرا Ù…ÛŒ*کند (مثل اضاÙÙ‡ یا به*روز کردن داده*ها)
- لایه*ÛŒ Business Logic صØت داده*های وارد شده توسط کاربر را بررسی Ù…ÛŒ*کند (داده*ها را اعتبارسنجی Ù…ÛŒ*کند)
- اگر داده*ها معتبر باشند آن*ها را برای به*روز رسانی در بانک اطلاعاتی به*دست لایه*ی دسترسی به داده می*سپارد.
مزیت*های برنامه*های چند لایه
- برنامه*ها به چند بخش منطقی جدا از هم تقسیم می*شوند و اتصال میان UI (رابط کاربری)، پردازش*ها و بانک اطلاعاتی کم می*شود.
- تغییر در بانک اطلاعاتی یا روال*های دسترسی به داده*ها، تاثیری در لایه*ی نمایش یا برنامه*ی کلاینت نخواهد گذاشت.
- برنامه*ی کلاینت با عبارات SQL آمیخته نخواهد شد.
- نام جداول Ùˆ ستون*ها به*طور مؤثری از برنامه*ÛŒ Client ØØ°Ù Ù…ÛŒ*شوند.
- برنامه*ÛŒ Client نمی*Ùهمد Ú©Ù‡ داده*ها از کجا آمده*اند (چیزی Ú©Ù‡ به آن Location Transparency Ú¯Ùته Ù…ÛŒ*شود)
- تغییر یا گسترش برنامه بسیار ساده*تر خواهد شد، بدون نیاز به تغییر یا کامپایل مجدد برنامه*ی Client.
نکته*ÛŒ منÙÛŒ در معماری چند لایه این است Ú©Ù‡ شما باید تعداد زیادی بخش*ها Ùˆ کلاس*های ازهم جدا در نرم*اÙزار بسازید. اما به هر Øال مزایای این روش بیش*تر Ùˆ برتر از معایب آن است.
انتخاب*های لایه*ی Presentation
دو انتخاب اصلی برای ساخت یک لایه*ÛŒ نمایش در دات نت وجود دارد. آن*ها Ùرم*های ویندوزی یا Ùرم*های وبی ASP.NET هستند.
با استÙاده از ویندوز Ùرم*ها شما Ù…ÛŒ*توانید برنامه*های دسکتاپ Ùرم Ù…Øور (Form Base) معمول را بسازید. برنامه*های ویندوز Ùرمی Ù…ÛŒ*توانند المان*های رابط کاربری بسیار غنی به*کاربر پیشنهاد کنند. آن*ها Ú©Ù… Ùˆ بیش شبیه به Ùرم*های ویژوال بیسیک هستند.
جذاب*ترین گزینه برای توسعه*ÛŒ لایه*ÛŒ نمایش استÙاده از وب Ùرم*های ASP.NET است. کنترل*هایی مثل: دیتاگرید، دیتالیست Ùˆ تقویم (Calendar) یک رابط کاربری قدرتمند را با مقدار Ú©Ù…ÛŒ کد Ùراهم Ù…ÛŒ*کنند.
انتخاب*هایی Ú©Ù‡ در بالا برای ساخت یک لایه*ÛŒ نمایش بررسی کردیم Ù…ÛŒ*توانند توسط زبان*های مختلÙÛŒ مثل C#Visual Studio.Net پیاده*سازی شوند.
انتخاب*های لایه*ی Business Logic
لایه*ی Business Logic از چندین بخش که کارهایی نظیر اعتبار سنجی کار، گردش کار یا کارهای مشابه را انجام می*دهند تشکیل شده است.
Componentهای .Net این لایه را Ø´Ú©Ù„ Ù…ÛŒ*دهند. شما Ù…ÛŒ*توانید با Interop از Componentهای COM استÙاده کنید ولی این کار کارایی را پایین خواهد آورد.
وب*سرویس*های ASP.NET هم Ù…ÛŒ*توانند به*عنوان یک Business Logic عمل کنند. اما به هر Øال آن*ها را نمی*توان در همه*ÛŒ شرایط به*عنوان جایگزین Componentها به*کار برد. وب*سرویس*ها تنها زمانی قابل استÙاده خواهند بود Ú©Ù‡ اعتبارسنجی در جایی بیرون از شبکه*ÛŒ شما اتÙاق اÙتاده باشد.
Componentهایی Ú©Ù‡ توسعه Ù…ÛŒ*دهید به ماندن روی ماشین*های مشابه نیازی ندارند. با استÙاده از دات NET Remoting Ù…ÛŒ*توانید آن*ها را روی چندین ماشین توزیع کنید.
انتخاب*های لایه*ی Data Access
این لایه با دستکاری داده*ها مثل اضاÙه، ØØ°Ù Ùˆ به*روز رسانی آن*ها سر Ùˆ کار دارد. داده*هایی Ú©Ù‡ به آن*ها اشاره کردیم Ù…ÛŒ*توانند در RDBMS یا XML قرار داشته باشند. شما باید لایه*ÛŒ دسترسی به داده را چنان طراØÛŒ کنید Ú©Ù‡ دیگر لایه*ها نیازی به دانستن وضعیت انبار داده*ها نداشته باشند.
ADO.NET Ùناوری دسترسی به داده*ÛŒ تØت دات .Net است. اگر Ú†Ù‡ ADO.NET از طریق کلاس*های DataReader اجازه*ÛŒ دسترسی به داده*های در هنگام اتصال را Ù…ÛŒ*دهد ولی بیش*ترین تمرکز روی دسترسی به داده*ها در زمان متصل نبودن است. DataSet نقش کلیدی را در این مورد بازی Ù…ÛŒ*کند. در بعضی موارد Ù…ÛŒ*توانید ADO را هم برای دسترسی به داده*ها استÙاده کنید ولی استÙاده از آن باید دلیل معتبری داشته باشد. از ADO استÙاده نکنید Ùقط به خاطر این*Ú©Ù‡ RecordSetها را دوست دارید!
این*جا هم Componentهای .Net لایه را تشکیل Ù…ÛŒ*دهند. همان*طور Ú©Ù‡ قبلا Ú¯Ùته شد Ù…ÛŒ*توانید از Componentهای کلاسیک COM هم استÙاده کنید.
هم*چنین وب*سرویس*ها هم Ù…ÛŒ*توانند لایه*ÛŒ دسترسی به داده را Ø´Ú©Ù„ دهند. این مخصوصا زمانی درست است Ú©Ù‡ DataBase شما Ùراهم*کننده*ÛŒ (Provider) داده ندارد. در این*گونه موارد شما Ù…ÛŒ*توانید مقداری کد برای اتصال به داده*ها Ùˆ پر کردن DataBaseها Ùˆ بازگرداندن نتایج درون DataSet به درخواست*کننده*ÛŒ داده بنویسید.
علاوه بر ADO.NET شما Ù…ÛŒ*توانید از امکانات سیستم مدیریت DataBase خود مثل توابع Ùˆ یا روال*های ذخیره شده (Stored Procedures) استÙاده کنید.
ارسال داده از یک لایه به لایه*ی دیگر
در تمام موارد به ارسال اطلاعات از یک لایه به لایه*ÛŒ دیگر نیاز است؛ به*طور معمول برنامه*نویسان از رشته*ها، آرایه*ها، RecordSetهای غیرمتصل برای رسیدن به این هد٠استÙاده Ù…ÛŒ*کنند. در .Net ØŒ DataSetها یک راه Ùوق*العاده برای انتقال اطلاعات میان لایه*ها Ùراهم Ù…ÛŒ*کنند. شما Øتی Ù…ÛŒ*توانید با برنامه*نویسی یک DataSet بسازید Ùˆ آن را با داده*های خودتان پر کنید. اگر اشیا را خیلی دوست دارید Ù…ÛŒ*توانید از Typed DataSets استÙاده کنید Ú©Ù‡ در واقع کلاسی مشتق شده از کلاس DataSet است Ú©Ù‡ جداول Ùˆ سطرها را به Ø´Ú©Ù„ یک Ø´ÛŒ معرÙÛŒ Ù…ÛŒ*کند.
منبع :http://www.roshd.ir
پیوست » از وقتی این ممد ادیتور را انگولک کرده Ùاصله ها در متنهای Ú©Ù¾ÛŒ پیست شده * میخورن به منم هیچ ربطی نداره