سوال: طراحي لايه ها [بایگانی]

Elham_gh

چهارشنبه 03 مهر 1387, 09:18 صبح

زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟

Modifier

چهارشنبه 17 مهر 1387, 17:06 عصر

سلام عليكم

اصلا مشكل بعضي از کساني که ميخوان بصورت شئ گرا طراحي کنن و از معماريه لايه اي استفاده کنن همين است.

بخصوص وقتي از فريم ورک دات نت ميخوان استفاده بکنن.
تو بعضي مواقع گيج کننده ست.

بعضي ها ميرن سراغ جاوا چون ميتونن دقيقا اون چيزي رو که ميدونن پياده کنن.

من زياد حرفه اي نيستم ولي ...
معمولا ما از معماريه 3 لايه يا n لايه استفاده ميکنيم
فريم ورک دات نت توي خيلي مواقع اومده براي راحتي کار کاربران ابزار هايي رو قرار داده که بصورت ويزارد مثلا لايه DAL رو پياده سازي ميکنه. اون وقت کدش رو تو لايه نمايش بايد بزاريم !!!

من که خودم خوشم نمياد از اون استفاده کنم ...

کلا راحت ترم که لايه ها ، کلاس ها ، متد هاي مربوط رو خودم بنويسم.

هدف مايکروسافت اينه که کد نويسي به حدالقل برسه.

اما بهتره کار خودمون رو بکنيم و در کنارش با اون ابزار ها هم آشنا باشيم (بعضي وقتها کار آدم رو زودتر راه ميندازه).

بحث زياده اگه فرصت شد بازم مينويسم ...

يا علي

KambizZandi

چهارشنبه 17 مهر 1387, 20:20 عصر

طراحي زياد ارتباط به platform نداره
شما بايد بتونيد مدلي رو طراحي کنيد که هر تيم developing اي با هر platform اي بتونه اونو پياده سازي کنه
اگر تو کتابهاي uml دقت کرده باشيد بيشتر مسالها روي soda machine زده ميشه که يک دستگاهي هست که پول ميگيره و قوطي نوشابه پس ميده.
متاسفانه بيشتر طراح ها موقع آناليز ميرن سراغ platform و کارو خراب ميکنن

afsharm

پنج شنبه 18 مهر 1387, 08:18 صبح

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

Modifier

پنج شنبه 18 مهر 1387, 15:31 عصر

سلام علیکم

زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟

میشه لطفا بگید کجا لایه به صورت اوتوماتیک تولید میشه ؟
البته من خودم گفتم که مثلا یه چیزی مثل لایه data access تولید میکنه ، ولی وقتی دقت میکنی چون در جای خودش قرار نمیگیره دیگه نمیشه بهش بگیم لایه چون لایه Dal در لایه نمایش قرار داده میشه.

طراحي زياد ارتباط به platform نداره
شما بايد بتونيد مدلي رو طراحي کنيد که هر تيم developing اي با هر platform اي بتونه اونو پياده سازي کنه
اگر تو کتابهاي uml دقت کرده باشيد بيشتر مسالها روي soda machine زده ميشه که يک دستگاهي هست که پول ميگيره و قوطي نوشابه پس ميده.
متاسفانه بيشتر طراح ها موقع آناليز ميرن سراغ platform و کارو خراب ميکنن

شما وقتی که میخواهید مدل های طراحی رو ایجاد کنید ، باید نسبت به زبان برنامه نویسی و امکانات اون شناخت خوب داشته باشید.
یک نکته رو همیشه گفته اند :
برای اینکه یک طراح خوب باشی باید قبلش ، مدتی خوب برنامه نویسی کرده باشید.
اون چیزی که شما دارید در موردش صحبت میکنید ، Analysis هست نه Design.
در Analysis هم کلاس دیاگرام داریم با جزئیات خیلی کمتر.
در Design عمدتا 3 قسمت زیر رو حتما داریم :
sequence
collaboration(نباشه هم طوری نیست.)
class
در مدل طراحی (Design model)برای کشیدن class ها باید نسبت به زبان و امکانات اون شناخت داشته باشید.

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

Microsoft.net

جمعه 19 مهر 1387, 08:16 صبح

خیلی از شرکت ها هستند که تولید خودکار این لایه ها رو در اختیار برنامه نویس قرار میدهند مثلا CodeSmith یا Nhibernate و ... ولی شخصا معتقدم اگه خودت بتونی یه tools بنویسی که بتونه این کار رو برات انجام بده و سورسشم دست خودت باشه در آینده انعطاف بیشتری خواهی داشت

javaphantom

جمعه 19 مهر 1387, 18:01 عصر

زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟

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

در صورتی که وقت بزاری و بری دنبال جواب این سوالات اون موقع متوجه می شی که اصلا سوالتون اشتباه بوده.

javaphantom

جمعه 19 مهر 1387, 18:06 عصر

طراحي زياد ارتباط به platform نداره
شما بايد بتونيد مدلي رو طراحي کنيد که هر تيم developing اي با هر platform اي بتونه اونو پياده سازي کنه
اگر تو کتابهاي uml دقت کرده باشيد بيشتر مسالها روي soda machine زده ميشه که يک دستگاهي هست که پول ميگيره و قوطي نوشابه پس ميده.
متاسفانه بيشتر طراح ها موقع آناليز ميرن سراغ platform و کارو خراب ميکنن

در جوابتون این رو می تونم فقط بگم که طراح کاملا وابسته به تکنولوژی باید عمل کنه تا بتونه طرحشو پیاده سازی کنه.
وقتی صحبت از تکنولوژی می شه بحث سخت افزار ، نرم افزار ، سیستم عامل و و و بوجود می آید.

در بخش انالیز سیستم می تونم تا حدی باهاتون هم عقیده باشم.

Microsoft.net

جمعه 19 مهر 1387, 19:40 عصر

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

در صورتی که وقت بزاری و بری دنبال جواب این سوالات اون موقع متوجه می شی که اصلا سوالتون اشتباه بوده.

شما دوست عزیز ظاهرا اطلاعاتت در این زمینه خیلی کمه ، این سوالهایی هم که کردی سالهاست جواب داده شده و به اثبات رسیده !
امروزه کسی نیست که امتیازات کار کردن در یک چهارچوب مشخص(Framework) رو انکار کنه ،امتیازات طراحی به روش لایه ای هم سالهاست که برای شرکت های نرم افزاری مشخص شده و بحث سر مزیتهای اون خودش یه کتابه و از حوصله این تاپیک خارج ، امروزه کمتر شرکت معتبری رو میتونی پیدا کنی که در طراحی محصولش به صورت لایه ای عمل نکرده باشه

سومین سوال اگر لایه ای وجود نداشته باشیم چگونه از frameworkها استفاده کنیم؟
.
آقای Zachman (با تلفظ صحیح زچمن) در دهه 70 میلادی در مقاله ای که بعدها به کتاب پرفروش Enterprises Unified Processign With Zachman Framework تبدیل شد اثبات کرد که هر نرم افزار کامپیوتری به حداقل 3 لایه منطقی تفکیک شده و مستقل از هم قابل تقسیم هست

javaphantom

جمعه 19 مهر 1387, 20:37 عصر

شما دوست عزیز ظاهرا اطلاعاتت در این زمینه خیلی کمه ، این سوالهایی هم که کردی سالهاست جواب داده شده و به اثبات رسیده !
امروزه کسی نیست که امتیازات کار کردن در یک چهارچوب مشخص(Framework) رو انکار کنه ،امتیازات طراحی به روش لایه ای هم سالهاست که برای شرکت های نرم افزاری مشخص شده و بحث سر مزیتهای اون خودش یه کتابه و از حوصله این تاپیک خارج ، امروزه کمتر شرکت معتبری رو میتونی پیدا کنی که در طراحی محصولش به صورت لایه ای عمل نکرده باشه

آقای Zachman (با تلفظ صحیح زچمن) در دهه 70 میلادی در مقاله ای که بعدها به کتاب پرفروش Enterprises Unified Processign With Zachman Framework تبدیل شد اثبات کرد که هر نرم افزار کامپیوتری به حداقل 3 لایه منطقی تفکیک شده و مستقل از هم قابل تقسیم هست

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

Modifier

شنبه 20 مهر 1387, 01:38 صبح

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

در صورتی که وقت بزاری و بری دنبال جواب این سوالات اون موقع متوجه می شی که اصلا سوالتون اشتباه بوده.

سلام

شما هم اشتباه کردید که این سوال های (فکر کنم میگن استفهامی) رو کردید چون ایشون خودشون میدونن ...

و بهتره مسئله رو حل کنیم ... نه اینکه سوال رو با سوال جواب بدیم

موفق باشید.

یا علی.

Elham_gh

شنبه 20 مهر 1387, 08:41 صبح

ببخشید , اما گویا یه کم اشتباه شد.
دوست عزیز ممنون که یاد آوری می کنی برم مفاهیم framework و لایه و... رو یاد بگیرم!!!
سئوال من چیز دیگه ای بود!!
من خودم 12 ساله دارم کار می کنم. و 8 ساله که طراحی می کنم! پس حداقل این مفاهیم و می دونم.
سئوال من این بود که تا حالا , در طراحی هام تمام لایه ها و .... هر چی که لازم بوده طراحی می کردم. الان خیلی از پیاده سازها به استفاده از framework ها روی اوردن. که خیلی از اینها لایه های مختلف یک application و ارتباط بین لایه ها رو پیاده سازی می کنه. حالا با وجود چنین fraemwork هایی طراحی لایه ها رو چطور باید دید؟؟؟

javaphantom

شنبه 20 مهر 1387, 17:48 عصر

زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟

می تونم نام یکی از فریم ورکهای استانداری که خودش لایه درست می کنه رو بدونم؟
اگر منظورتون ایجاد لایه های منطقی که از طریق pattern mvc هست که امروزه به اون معمار سه لایه هم گفته می شه که خود این معماری سه لایه جای بحث و گفته گو داره چون این pattern رو شما می تونید در یک معاری دو لایه و همینطور n لایه استفاده بکنید. ربطی به فریم ورک نداره این یک pattern هست و اگر frameworkی اونرو پیاده سازی می کنه مثل struts که تازه استادارد هم نیست ربطی به معماری چند لایه نداره.
فریم ورک spring روی pattern دیگه ای به نام Dependency Injection کار می کنه. یا مثلا فریم ورک hibernate که یک فریم ورک مستقل در لایه مخصوص خودش هست.

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

javaphantom

شنبه 20 مهر 1387, 18:03 عصر

ببخشید , اما گویا یه کم اشتباه شد.
دوست عزیز ممنون که یاد آوری می کنی برم مفاهیم framework و لایه و... رو یاد بگیرم!!!
سئوال من چیز دیگه ای بود!!
من خودم 12 ساله دارم کار می کنم. و 8 ساله که طراحی می کنم! پس حداقل این مفاهیم و می دونم.
سئوال من این بود که تا حالا , در طراحی هام تمام لایه ها و .... هر چی که لازم بوده طراحی می کردم. الان خیلی از پیاده سازها به استفاده از framework ها روی اوردن. که خیلی از اینها لایه های مختلف یک application و ارتباط بین لایه ها رو پیاده سازی می کنه. حالا با وجود چنین fraemwork هایی طراحی لایه ها رو چطور باید دید؟؟؟

لایه های مختلف یک application ؟
اگر منظورتون application های سازمانی Enterprise باشه در پست قبلی هم گفتم هر فریم ورکی باید توی لایه خودش اعمال وظیفه کنه بازم تولید لایه نمی کنه. من کار به استاندارد عقب مونده ماکروسافت ندارم که چه معماری استفاده می کنه. منظور من فریم ورکهای استاندارد بزرگی هست که امروزه برای برنامه های سازمانی بزرگ استفاده می شه و اونها هیچ کدام لایه درست نمی کنند یا لایه های application رو طراحی، تولید یا هرچی که دوست دارید بزاریداسمشونو تولید نمی کنند.

ما بحثی داریم به نام component و به دنبال اون SOA (service oriented architeture) بحث استاندار بودن و به دنبال اون معماری نرم افزار. من به شخصه تا حالا ندیدم فریم ورکی بیاد و تمامی این لایه ها رو بسازه یا تولید کنه بعد ارتباط بین اونها رو برفرار کنه، کار رو تمموم کنه بره.

اگر شما همچین فریم ورکی رو دارید از من به شما نصحیت البته من کوچیک شما هم هستم شما استاد بنده هستید ولی استفاده نکنید بهتره.

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

Elham_gh

یک شنبه 21 مهر 1387, 08:45 صبح

می تونم نام یکی از فریم ورکهای استانداری که خودش لایه درست می کنه رو بدونم؟

LLBL و netTiers

whitehat

یک شنبه 21 مهر 1387, 20:12 عصر

در مورد موضوع صحبت کنید،پستهای نامرتبط پاک شدند

Modifier

دوشنبه 22 مهر 1387, 16:05 عصر

LLBL و netTiers

من تا حالا دنبال این جور فریم ورک ها نبودم

اصلا نمیدونستم ...

ا زکدوم شرکت هستند ؟ قابل دانلود هست تا ما هم استفاده کنیم شاید به نتایجی رسیدیم ..

تا حالا من متوجه چیز دیگری بودم . جواب سوال شما رو میدادم و تا حالابا این نرم افزار ها کار نکردم که بتونم جواب دقیقی بدم.

ممنون

یا علی

Elham_gh

سه شنبه 23 مهر 1387, 07:53 صبح

دوست گرامی Modifier ,
من هم رسما با اینها هنوز کار نکردم. اما خوب استراتژی بسیاری از شرکتها و سازمانها الان داره به این سمت می ره. اینکه بشه free تو اینترنت پیدا کرد یا نه رو نمی دونم. اما احتمال زیاد هست چون خیلی هاشون که اصلا Open source هستند.

KambizZandi

سه شنبه 30 مهر 1387, 03:19 صبح

مشکل اينه که بيشتر برنامه نويسان سعي ميکنن خودشون رو در اجراي تمام قسمت هاي پروژه دخيل بدونن
منم اولا که داشتم برنامه نويسي ياد ميگرفتم (19 سال پيش) همينجوري بودم تا اينکه چند سال پيش وقتي با يکي دو تا تيم اونوري کار کردم تازه فهميدم که دانشگاه هاي اينجا و ebook هايي که هي دست به دست ميگرده و خلاصه تمام اين مواردي رو که ما بهشون استناد ميکنيمو بايد از نو بررسي کرد و چشم بسته به هيچ چيزي اعتماد نکرد.
قبلا گفتم و بازم ميگم بحث طراحي (حالا شما ها هر اسمي ميخواين روش بذارين) نبايد!! وابسته به زبان برنامه نويسي باشه که البته اين موضوع با توجه به نوع پروژه قابل بحث و مدل سازي هست.
مثلا در يک سيستم عامل قطعا نميشه platform رو نديده گرفت (کما اينکه اونم ميشه) ولي هرچه بيشتر به سطح برنامه هاي کاربردي نزديک ميشيم اين وابستگي بايد کم بشه.
من يک مدلي رو چند وقت پيش طراحي کردم که 36 تا لايه داشت. برنامه نويسايي بودن که به اين مدل ايراد ميگرفتن و نميتونستن اونو اجرا کنن اما با بچه هاي اونور براحتي اين پروژه اجرا شد. چون ديد آدم بايد صحيح باشه و هي به چيزايي که بلديم گير نديم.
بقيشو بعدا ميگم.

Elham_gh

سه شنبه 30 مهر 1387, 07:52 صبح

دوست عزیز KambizZandi
با فرض اینکه محیط پیاده سازی تاثیر گذار نیست در طراحی, حالا اگه طراحی تو طراحیش بیاد و از MultiInheritance استفاده کنه. برنامه نویس Net. چطور اونو پیاده کنه؟

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

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

mak1387

سه شنبه 30 مهر 1387, 08:57 صبح

زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟

اگر به لايه هايي که توسط Framework هابه طور اتوماتيک توليد ميشوند و Interface آن ها آگاهي داشته
باشيد ; چه ايرادي دارد که از آنها استفاده نکنيد؟ و اگر لايه هايي که لازم داريد در Framework موجود نيست يا شما اطلاعي از آن نداريد چه چاره اي غير از طراحي و توليد آن داريد؟

_samaneh_m

سه شنبه 30 مهر 1387, 09:21 صبح

زماني كه يك سيستم طراحي مي شه، بايد تمم لايه ها و ازتباطاتشان و ...همه و همه چيز طراحي شه.
اما الان با رشد فراگير استفاده از framework ها گوناگوني كه در بازار ارائه مي شهة آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟

اگر به لايه هايي که توسط Framework هابه طور اتوماتيک توليد ميشوند و Interface آن ها آگاهي داشته
باشيد ; چه ايرادي دارد که از آنها استفاده نکنيد؟ و اگر لايه هايي که لازم داريد در Framework موجود نيست يا شما اطلاعي از آن نداريد چه چاره اي غير از طراحي و توليد آن داريد؟

این جواب من بود یا توضیح سئوال من؟ چون من دقیقا همین سئوال رو دارم. با این تفاوت که ما همیشه مسلما می دونیم که farmework مون چه لایه هایی رو ایجاد می کنه. اما دقیقا سئوال من همینه "آيا لزومي به طراحي لايه هايي كه اتوماتيك توسط framework ساخته مي شه هست؟"
ممنون

Elham_gh

سه شنبه 30 مهر 1387, 09:33 صبح

شرمنده . پشت دستگاه همکارم نشسته بودم که پیغام قبلی را پست کردم. حواسم نبود به اسم ایشون ثبت شد. پست قبلی مربوط به من هست .

بازم معذرت می خوام.

Elham_gh

سه شنبه 30 مهر 1387, 10:21 صبح

مشکل اينه که بيشتر برنامه نويسان سعي ميکنن خودشون رو در اجراي تمام قسمت هاي پروژه دخيل بدونن
منم اولا که داشتم برنامه نويسي ياد ميگرفتم (19 سال پيش) همينجوري بودم تا اينکه چند سال پيش وقتي با يکي دو تا تيم اونوري کار کردم تازه فهميدم که دانشگاه هاي اينجا و ebook هايي که هي دست به دست ميگرده و خلاصه تمام اين مواردي رو که ما بهشون استناد ميکنيمو بايد از نو بررسي کرد و چشم بسته به هيچ چيزي اعتماد نکرد.
قبلا گفتم و بازم ميگم بحث طراحي (حالا شما ها هر اسمي ميخواين روش بذارين) نبايد!! وابسته به زبان برنامه نويسي باشه که البته اين موضوع با توجه به نوع پروژه قابل بحث و مدل سازي هست.
مثلا در يک سيستم عامل قطعا نميشه platform رو نديده گرفت (کما اينکه اونم ميشه) ولي هرچه بيشتر به سطح برنامه هاي کاربردي نزديک ميشيم اين وابستگي بايد کم بشه.
من يک مدلي رو چند وقت پيش طراحي کردم که 36 تا لايه داشت. برنامه نويسايي بودن که به اين مدل ايراد ميگرفتن و نميتونستن اونو اجرا کنن اما با بچه هاي اونور براحتي اين پروژه اجرا شد. چون ديد آدم بايد صحيح باشه و هي به چيزايي که بلديم گير نديم.
بقيشو بعدا ميگم.

با یک مطلب دیگه هم برخورد کردم در سایت مایکروسافت.در سایت اومده مدرک MCSD برای کسانی مناسب است که:

Choose the MCSD credential if you:
• Analyze and design leading-edge enterprise solutions with Microsoft development tools, technologies, and platforms.

• Have at least two years of experience in a lead developer role analyzing business and technical requirements, and defining solution architecture.

و بعدش می گه مطالبی که برای گرفتن این مدرک لازم دارید بلد باشید عبارتند از:

Core exams: Web Application Development
Exam 70-3051: Developing and Implementing Web Applications with Microsoft Visual Basic .NET and Microsoft Visual Studio .NET

Exam 70-3151: Developing and Implementing Web Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET

Core exams: Windows Application Development
Exam 70-3061: Developing and Implementing Windows-based Applications with Microsoft Visual Basic .NET and Microsoft Visual Studio .NET

Exam 70-3161: Developing and Implementing Windows-based Applications with Microsoft Visual C# .NET and Microsoft Visual Studio .NET

Core exams: Web Services and Server Components Development

Exam 70-3101: Developing XML Web Services and Server Components with Microsoft Visual Basic .NET and the Microsoft .NET Framework

Exam 70-3201: Developing XML Web Services and Server Components with Microsoft Visual C# and the Microsoft .NET Framework

Core exam: Solution Architecture

Exam 70-3001: Analyzing Requirements and Defining Microsoft .NET Solution Architectures

Elective exams
Exam 70-2291: Designing and Implementing Databases with Microsoft SQL Server 2000 Enterprise Edition

Exam 70-2302: Designing and Implementing Solutions with Microsoft BizTalk Server 2000 Enterprise Edition

Exam 70-2342: Designing and Implementing Solutions with Microsoft Commerce Server 2000

Exam 70-235: TS: Developing Business Process and Integration Solutions Using Microsoft Biztalk Server 2006

Exam 70-3011: Managing, Organizing, and Delivering IT Projects by Using Microsoft Solutions Framework 3.0

Exam 70-3301: Implementing Security for Applications with Microsoft Visual Basic .NET

Exam 70-3401: Implementing Security for Applications with Microsoft Visual C# .NET

Exam 70-431: TS: Microsoft SQL Server 2005 – Implementation and Maintenance

Exam 74–135: Developing E-Business Solutions Using Microsoft BizTalk Server 2004

KambizZandi

سه شنبه 30 مهر 1387, 14:47 عصر

دوست عزیز KambizZandi
با فرض اینکه محیط پیاده سازی تاثیر گذار نیست در طراحی, حالا اگه طراحی تو طراحیش بیاد و از MultiInheritance استفاده کنه. برنامه نویس Net. چطور اونو پیاده کنه؟

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

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

سلامت باشيد

ببينيد حرف من کلا اينه که هر جايگاهي در مسير پروژه بايد ايزوله بشه تا نتيجه ي خوبي بگيريم. اين حرف من توهين به ذهنيت افراد اينجا که به نوعي همکار من تلقي ميشن نيست. اما منظور اينه که طراح نبايد کاري به اجرا داشته باشه. اجرا نبايد کاري به تست داشته باشه. آناليز نبايد تو کار بقيه دخالت کنه و ...
اصلا به خاطر همين چيزاست که uml و rup و ... بوجود اومدن.
اما موضوع اينه که يک برنامه نويس حرفه اي وقتي مدلي استانداري رو براي اجرا بهش ميدن ديگه خودش بايد بتونه از پس اون بر بياد.
مثلا همين multi inheritance رو هر برنامه نويسي با روش خاصي ميتونه حل کنه مثل استفاده از interface با مديريت مرکزي عناصر که البته همه جا خوب نيست چون گلوگاه ايجاد ميکنه يا حتي استفاده از property هايي که به کلاسهاي خاصي وصل ميشن.
به هر حال من احساس ميکنم اين بحث داره تبديل به يک مقاله خوب و ارزشمند ميشه و بسيار مايلم دوستان ديگر هم طرح نظر کنن تا همه بتونيم مطالب جديدي ياد بگيريم.

Elham_gh

سه شنبه 30 مهر 1387, 15:47 عصر

اما دوست عزیز , جناب KambizZandi
بحث من اصلا دخالت برنامه نویس ویا بالعکس نیست. من هیچ دخالتی تو کار برنامه نویسامون ندارم. اونا هم کاری به کار من ندارند.
الان سیاست کاری بر مبنای استفاده از یک فریم ورک آماده است. که این فریم ورک 5 لایه می سازه.
من نمی تونم به عنوان طراح بیام یک سیستم با معماری 3 لایه طراحی کنم که هیچ ربطی هم به لایه هایی که توسط فریم ورک ساخته می شه نداره. می تونم؟
حالا می گم من به عنوان طراح چی کار کنم؟ اون لایه ها رو تو طراحیم بیارم ؟ که جالب نیست. نیارم که خوب نمیشه!!! پس چه کنم؟

بعدشم اینکه شما می گید برنامه نویس خودش می دونه که چه جوری multiInheratance رو پیاده کنه , که با توجه به سواد نه چندان بنده درست نیست.درسته؟
دوستان دیگه نظری در این مورد ندارند؟

KambizZandi

سه شنبه 30 مهر 1387, 16:28 عصر

من فکر ميکنم موضوع طراحي application با موضوع نقشه هاي اجراي يک طراحي قاطي شده
هر کدوم موضوع جداگانه اي هستند
ممکن هست در طراحي نقشه ي اجرايي يا همون developing diagram ها لايه ها رو بياريم اما آوردن لايه ها در طراحي اصلي application رو تا حالا نشنيده بودم
اين موضوع برميگرده به اينکه يک تيم بياد و کل پروژه رو از 0 تا 100 طراحي کنه که اينکار غلطه. بلکه هر تيم پس از دريافت طراحي اصلي خودش مياد و با توجه به توانايي هاش طراحي لايه هاي زيرين رو انجام ميده
موفق باشيد

vcldeveloper

سه شنبه 30 مهر 1387, 16:43 عصر

اما منظور اينه که طراح نبايد کاري به اجرا داشته باشه. اجرا نبايد کاري به تست داشته باشه. آناليز نبايد تو کار بقيه دخالت کنه و ...کی همچین چیزی گفته؟! مثلا یکی بخواد بصورت Test-Driven کار کنه، چطور میتونه در مراحل مختلف پروژه کاری به تست نداشته باشه؟!
حتی مایکروسافت هم به این نتیجه رسیده که اینی که شما میگید، نتیجه جالبی نداره:
http://blogs.msdn.com/e7/archive/2008/10/15/engineering-7-a-view-from-the-bottom.aspx

ایزوله کردن لایه های یک نرم افزار به معنای ایزوله کردن کار تیم نرم افزاری از هم نیست. البته منظور دخالت در کار هم نیست، بلکه باید از کار هم آگاه باشند، و حتی در بخش هایی از کار دیگران مشارکت داشته باشند.

Elham_gh

چهارشنبه 01 آبان 1387, 07:28 صبح

من فکر ميکنم موضوع طراحي application با موضوع نقشه هاي اجراي يک طراحي قاطي شده
هر کدوم موضوع جداگانه اي هستند
ممکن هست در طراحي نقشه ي اجرايي يا همون developing diagram ها لايه ها رو بياريم اما آوردن لايه ها در طراحي اصلي application رو تا حالا نشنيده بودم
اين موضوع برميگرده به اينکه يک تيم بياد و کل پروژه رو از 0 تا 100 طراحي کنه که اينکار غلطه. بلکه هر تيم پس از دريافت طراحي اصلي خودش مياد و با توجه به توانايي هاش طراحي لايه هاي زيرين رو انجام ميده
موفق باشيد

این دیگه جدید بود.
الان داره طراحی به سمتی می ره که تا جای ممکن همه چی مدل شه تا برنامه نویس کمترین اثر و تصمیم رو داشته باشه تا جایی که دارن هرروز بیشتر روی case tools ها کار می کنند که بتونه خودش کد لازم رو تا جای ممکن پیاده کنه. حتی تا طراحی و مشخص کردنstored procedure ها.
با این حرف شما 2 تا شاخ الان روی سر اینجانب سبز شده.
حتی شرکت موفقی رو تو تهران می شناسم که اولین شرکتی بود که از RUP استفاده کرد و وقتی با مدیر عاملش حرف می زدم(4 سال پیش) می گفت ما اصلا کد نمی زننیم, فقط مدلهامونو درست در میاریم.و ابزار کدمونو تولید می کنه. البته با اون اغراق قبول نداشتم و لی خوب. این روش کار درسته.
ببنید RUP چند نقش برای آنالیز و طراحی در نظر گرفته و با چه ظرافتهایی و چند نقش برای پیاده ساز. برای اینکه تا اونجا که ممکنه از اعمال سلیقه برنامه نویس جلو گیری شه.

KambizZandi

چهارشنبه 01 آبان 1387, 09:23 صبح

حتما حق با شماست
اما تجربه ي من و کارهاي موفقي که ديدم چيز ديگه اي ميگه
اگر قرار باشه هر کسي تو پروژه يه چيزي به فکرش برسه و اونو اجرا کنه که سنگ رو سنگ بند نميشه
هرکسي از طراح گرفته تا تستر بايد کارشو طبق الگوهايي که براش تعريف ميشه انجام بده و 100 البته از هنر خودشم براي بهترين حالت اجرا استفاده کنه
اما اگر بخواد تا يک ايده به ذهنش رسيد اونو اجرا کنه که پروژه از بين ميره
بنابراين طراحان بخش هاي مختلف (حتي طراحي و مدلينگ تست) وطيفشون اينه که تمام نقشه ها رو با دقت بکشن نه اينکه يه چيزي بگن و بقيه رو تو دردسر بندازن
موفق باشيد

vcldeveloper

چهارشنبه 01 آبان 1387, 10:53 صبح

اگر قرار باشه هر کسي تو پروژه يه چيزي به فکرش برسه و اونو اجرا کنه که سنگ رو سنگ بند نميشه
هرکسي از طراح گرفته تا تستر بايد کارشو طبق الگوهايي که براش تعريف ميشه انجام بده و 100 البته از هنر خودشم براي بهترين حالت اجرا استفاده کنه
اما اگر بخواد تا يک ايده به ذهنش رسيد اونو اجرا کنه که پروژه از بين ميره
بله، هر کس باید مطابق الگویی که براش تعریف شده کار کنه، ولی باید در این کار تعامل مناسبی با سایر افراد داشته باشه. بخصوص که هر Iteration وقتی شروع میشه، بازخورد کار تمامی افراد تیم (طراح، تستر، برنامه نویس، و...) در Iteration قبلی، بر آن اثر میزاره.
طراح وظیفه مدیریت تکنیکی (نه تجاری یا مدیریتی) پروژه را برعهده داره، پس باید تعاملش با سایر اعضاء بیشتر باشه، هر اعضاء به وی به عنوان یک تکیه گاه مطمئن نگاه کنند. طراح نباید مانع از ابراز ایده های افراد شود. بلکه باید ایده ها را راهبری کند تا به آنچیزی که در Vision مدنظر قرار گرفته نزدیک شوند. برنامه نویس یا Tester ایی که ابتکار عمل و امکان بیان ایده هایش ازش گرفته شود، محصول خوبی هم تولید نمی کند! شما سعی می کنید نخبه ترین و بهترین افراد را برای تیم خودتان جمع آوری کنید، در هنگام استخدام به استعدادهای آنها و توانایی هایشان دقت می کنید، پس منطقی نیست که وقتی آنها را استخدام کردید، ایده و ابتکار عملشان را از آنها بگیرید، و از آنها انتظار داشته باشید که مثل یک ماشین بی فکر فقط ایده های شما را پیاده سازی کنند! اگر به آنها و ایده هایشان بها بدهید، و ایده های آنها را در کانال های مناسبی که می دانید به سود پروژه هست، هدایت کنید، محصول شما کیفیت بیشتری خواهد داشت. اعضاء تیم شما هم رضایت بیشتری خواهند داشت. یک طراح خوب باید مطمئن شود که اعضاء تیمش به طرح آماده شده و مسیری که طی می کنند اعتقاد دارند، و آن را کاملا درک می کنند. برای اینکه این اعتماد بوجود بیاد، طراح باید در تمامی مراحل کار اعضاء تیمش حضور داشته باشه، البته نه اینکه در کارهای تیم دائما دخالت کند، و حرف خودش را به کرسی بنشاند، بلکه با اعضاء تیم همراه باشد، نظراتشان را بشنوند، هر جا از وی راهنمایی خواستند، به آنها کمک کند، هر جا احساس کرد انتقادی از وی یا طرحش وجود دارد، دیدگاههای منتقدات را با رعایت انصاف بشنود، اشتباهات خودش را به راحتی قبول کند. این نوع رفتار باعث می شود که به مرور اعضاء تیم با نظرات و طرز فکر یکدیگر، بخصوص ایده های طراح بیشتر آشنا شوند، و توانایی های یک دیگر را بهتر بشناسند. در این صورت، طراح زحمت کمتری برای توجیه اعضاء تیم خواهد کشید، چون اعضا بیشتر با طرز فکر او آشنا هستند، و با یک توضیح مختصر هم متوجه منظور وی می شوند.

بنابراين طراحان بخش هاي مختلف (حتي طراحي و مدلينگ تست) وطيفشون اينه که تمام نقشه ها رو با دقت بکشن نه اينکه يه چيزي بگن و بقيه رو تو دردسر بندازن
از نظر من نمودارهای بسیار دقیق فقط زمانی واقعا کاربرد دارند که Implementer شما یک نرم افزار زبان نفهم باشد که باید همه جزئیات را برایش مشخص کرد، وگرنه کدهای بی کیفیت تولید می کند. اما برای اعضاء تیم باید به جزئیات نمودارها تا حدی پرداخته شود که برای اعضاء قابل درک باشد.