سئوالات و مباحث WPF

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
آها . همین رو میخواستم بدونم . به نظرم چیزی که دنبالش میگشتم ، همین خطی که بولد کردم ، هست .
البته Model در MVVM ، با لایه ی "منطق تجاری" و لایه ی مربوط به "دیتابیس" در معماری 3 لایه ، فرقی نداره (بجز حالا فرضا بخشی از Model که در MVVM ممکنه در ViewModel بره) . درسته؟

اگه آره ، پس در MVVM نسبت به معماری 3 لایه ، صرفا بحث سازگار کردنِ بخشِ View یا منطق ارائه ، با Model هست . یعنی به عبارتی تفاوت MVVM (یا هر عبارت دیگه ای که میگید) با معماری 3 لایه ، اینه که در MVVM ، راحت تر و سریعتر لایه ی View را با لایه ی Model میشه هماهنگ کرد (معکوس اش ، نسبت به معماری 3 لایه ، فرقی نداره) .

چون شما در معماری 3 لایه ، در لایه ی منطق تجاری و لایه ی دیتابیس ، هر چیزی که داشته باشید ، عدل ، همه ی اینها را به عنوان لایه ی Model میتونید در یه پروژه ی دیگه در معماری MVVM منتقل کنید بدون هیچ تغییری در این لایه ها .

بنابراین فقط بحث هماهنگ کردن لایه ی View (و انتقالش و هماهنگ کردنش) با لایه ی Model هست که لایه ی ViewModel ، این هماهنگی را راحت تر و سریعتر میکنه .

درسته؟
تشکر استاد :rose:
ببخشید زیاد شد .

سلامی مجدد
خیلی ممنون استاد از جواب خوب تون .

نظرتون درباره ی این تیکه از صحبتم چیه؟
درسته؟
دقت کنید که این صحبتم ، در پازل مقایسه بین MVVM و معماری 3 لایه هست ها .

تشکر استاد :rose:
 

the_king

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

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
ViewModel قراره یک لایه سبکی ای باشه که این امکان رو طراحان نرم افزار بده تا به سادگی و در مدت زمان کم Model های مختلف رو با View های مختلف هماهنگ کنند. اما در معماری سه لایه Application خودش مسئولیت قابل توجهی داره، یک لایه بزرگ و پیچیده است، به سادگی نمیشه تغییرش داد. اگر تغییری در لایه Presentation یا Database رخ بده، دستکاری لایه سنگین Application لازم میشه.

سلامی مجدد
خیلی ممنون استاد .

استاد ، این ویژگی ای که نام بردین ، در جواب همون قسمتی از پستم که سئوال پرسیدم بود دیگه .
یعنی مزیتِ اضافی ترِ mvvm نسبت به معماری 3 لایه بود دیگه . درسته؟
یعنی همه ی مزایای mvvm نیست . درسته؟ فرضا مزیت mvvm نسبت به معماری یک لایه یا دو لایه نیست . درسته؟

در لینک های زیر :


و


و


مهمترین مزایای معماری 3 لایه را قابلیت همزمان نوشتن هر لایه توسط تیم توسعه بخاطر اجرای هر لایه در زیر ساخت مربوط به خودش هست ، نام میبرن .
مزایای دیگه ی این معماری را هم توسعه ی سریعتر ، بهبود Scale (که نمیدونم دقیقا این Scale چیه؟) و نگهداری راحت تر و اطمینان بهتر (که منظورشون از اطمینان را هم دقیق متوجه نشدم) هست .

همه ی این مزایا را برای معماری mvvm ، در سایت های مختلف هم بیان کرده بودن .
پس ، همه ی مزایای mvvm ، میشه همین ها (مزایای معماری 3 لایه) به اضافه ی چیزی که شما گفتین و نقل قول کردم در این پست ازتون . درسته؟
البته قابلیت تست راحت ترِ unit test را برای mvvm هم علاوه بر اونها آوردن .

تشکر استاد :rose:
 

the_king

مدیرکل انجمن
سلامی مجدد
خیلی ممنون استاد .

استاد ، این ویژگی ای که نام بردین ، در جواب همون قسمتی از پستم که سئوال پرسیدم بود دیگه .
یعنی مزیتِ اضافی ترِ mvvm نسبت به معماری 3 لایه بود دیگه . درسته؟
به چیزی که میگید، فکر کنید. پرتقال مزیتش نسبت به میوه چیه در حالی که خودش میوه است؟ اینجا مزیت که اصلا معنی نداره.
Window چه مزیتی نسبت به Control داره؟ مزیت اینجا معنی نداره. Window یک Control ئه که ویژگی های فلان رو داره. این ویژگی ها ممکنه با ویژگی های ListBox یا DataGridView یا موارد مشابه که همه شون هم مثل خودش Control هستند تشابه یا تفاوت هایی داشته باشند.
Control و Window همطراز نیستند که بخواهید با هم مقایسه شون کنید. معماری سه لایه و MVVM هم همینطور.
شما چیزی رو می توانید با چیز دیگری مقایسه کنید که همطراز باشند، تا حالا یک مقاله معتبر در سایتی دیده اید که یک چیزی رو با ذات خودش مقایسه کرده باشه، مزیت چیزی رو نسبت به ذاتش گفته باشه؟ در هر موضوع دلخواهی، کوکاکولا رو با نوشیدنی گازدار مقایسه کرده باشه، زن رو با انسان مقایسه کرده باشه، گنجشک رو با پرنده مقایسه کرده باشه، قرمز رو با رنگ مقایسه کرده باشه، بگردید ببینید همچین مقایسه ای در موضوعی هست؟ جستجو کنید از سال 2005 که صحبت MVVM شده تا حالا یک مقاله درست و حسابی، نمیگم صد تا، فقط یک مقاله در مورد مقایسه MVVM و معماری سه لایه هست که بگید منطق درستی داره و من هم دارم همونکار رو می کنم؟
یعنی همه ی مزایای mvvm نیست . درسته؟ فرضا مزیت mvvm نسبت به معماری یک لایه یا دو لایه نیست . درسته؟
مزایا و معایب برای مقایسه دو طرفی که همطراز هستند معنی داره. معماری یک لایه یا دو لایه همطراز MVVM نیستند که بتوانید با هم مقایسه شون کنید.
در لینک های زیر :


و


و


مهمترین مزایای معماری 3 لایه را قابلیت همزمان نوشتن هر لایه توسط تیم توسعه بخاطر اجرای هر لایه در زیر ساخت مربوط به خودش هست ، نام میبرن .
مزایای دیگه ی این معماری را هم توسعه ی سریعتر ، بهبود Scale (که نمیدونم دقیقا این Scale چیه؟) و نگهداری راحت تر و اطمینان بهتر (که منظورشون از اطمینان را هم دقیق متوجه نشدم) هست .
اگر اون مطالب رو با دقت بخونید می بینید که یا اصلا معماری سه لایه رو با چیزی مقایسه اش نکرده و صرفا فواید و معایب معماری سه لایه رو نوشته یا در یک مورد خاص با معماری دو لایه و سه لایه مقایسه اش کرده. از فواید الکل اینه که ضد عفونی کننده است، آیا من اینجا الکل رو با چیزی مقایسه کردم؟
توجه کنید و ببینید در مطالب چی با چی مقایسه شده، یا اصلا مقایسه ای در کار هست یا نه.
همه ی این مزایا را برای معماری mvvm ، در سایت های مختلف هم بیان کرده بودن .
پس ، همه ی مزایای mvvm ، میشه همین ها (مزایای معماری 3 لایه) به اضافه ی چیزی که شما گفتین و نقل قول کردم در این پست ازتون . درسته؟
البته قابلیت تست راحت ترِ unit test را برای mvvm هم علاوه بر اونها آوردن .
مزایای یک چیزی رو باید نسبت به چیز دیگری بسنجید، نسبت به چی مزیت داره؟ فرضا شما می خواهید بگید MVVM سرعت توسعه بیشتری داره، نسبت به کدوم معماری؟ یکجا میخونید که کاربری نوشته MVVM هزینه توسعه زیادی داره، نسبت به کدوم معماری هزینه بیشتری داره؟ نسبت به هر چی معماری در عالم بوده یا خواهد بود؟
 

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
سلامی مجدد
خیلی ممنون استاد .

استاد ، با این حرف زیر ام موافقید یا اگه نسبی هه ، تا چقدر موافقید؟ :

"تغییر در ماهیت User Interface ، نتیجه ی تغییر در Model هست" .

منظورم از تغییر ماهیت ، فرضا وقتی هست که در یک نسخه در UI ، یک combobox ای داشته باشیم (یا نداشته باشیم) اما در نسخه ی بعدی از همون UI ، اون کمبوباکس را حذف (یا اضافه) کنیم .
چون اول ، تصمیم گرفته میشه که یک قابلیتی (فرضا پروپرتی ای) را درون Model اضافه (یا حذف) کنیم و به نسبت اون تغییر هست که نیاز داریم تا ماهیت UI را تغییر بدیم (یا بسازیم) .

پس این طور نیست که وقتی ماهیت UI تغییر کنه ، به این دلیل باشه که Model مون تغییر میکنه . بلکه تغییر در Model مون بود که باعث تغییر در ماهیت UI مون شد .

از طرفی "تغییر در ظاهر (مثل تغییر در پوسته یا استایل یا template ئه) UI هم که اصلا باعث هیچ تغییری در Model نمیشه" .

نتیجه اینکه "اینکه با تغییر حتی UI ، لایه ی Model مون تغییر کنه ، موضوعیت نداره . بلکه موضوعیت و محوریت ، با تغییر Model هست . یعنی با تغییر Model هست که ممکنه ماهیت UI مون تغییر کنه" .

تشکر استاد .
 

the_king

مدیرکل انجمن
سلامی مجدد
خیلی ممنون استاد .

استاد ، با این حرف زیر ام موافقید یا اگه نسبی هه ، تا چقدر موافقید؟ :

"تغییر در ماهیت User Interface ، نتیجه ی تغییر در Model هست" .
اگر عبارت "تغییر در x نتیجه تغییر در y هست." درست باشه باید با تغییر در y ناگزیر و حتمی x تغییر کنه چون این نتیجه همچین عملی بوده.
حالا یک مثال رو فرض کنید که شما یک User Interface دارید که یک متن رو از کاربر میگیره و با صدای مرد یا زن میخونه. در نسخه قبلی Model بر اساس یک تکنیک ابتدایی پایگاه داده اصوات از قبل ضبط شده طراحی شده که متن ورودی رو به صوت تبدیل می کرده و حالا در نسخه جدید به یک هوش مصنوعی با یک سرویس آنلاین تغییر کرده که متن ورودی رو به صوت تبدیل می کنه. در Model یک تغییر اساسی رخ داده، معماری بانک اطلاعاتی و منطق تجاری کلا تغییر کرده. اما واسط کاربری همچنان همونه که بود، اصلا تغییر نکرده. همچنان متن رو از کاربر میگیره و صوت حاصل رو پخش میکنه.
منظورم از تغییر ماهیت ، فرضا وقتی هست که در یک نسخه در UI ، یک combobox ای داشته باشیم (یا نداشته باشیم) اما در نسخه ی بعدی از همون UI ، اون کمبوباکس را حذف (یا اضافه) کنیم .
حالا مثال قبلی رو با شرایط جدید تصور کنید. در نسخه قبلی پایگاه داده فقط دو نسخه صدای زن و مرد داشت و در نتیجه واسط کاربری در نسخه دوم همچنان فقط گزینه صدای زن و مرد داره. حالا در نسخه سوم واسط کاربری صدای بچه رو هم اضافه می کنند چون هوش مصنوعی Model این قابلیت رو داره که با مشخصات متفاوت صوت تولید کنه. Model در نسخه سوم نسبت به دوم هیچ تغییری نکرده، اما واسط کاربری تغییر می کنه. تغییر در واسط کاربری ربطی به تغییر در Model نداشت.
چون اول ، تصمیم گرفته میشه که یک قابلیتی (فرضا پروپرتی ای) را درون Model اضافه (یا حذف) کنیم و به نسبت اون تغییر هست که نیاز داریم تا ماهیت UI را تغییر بدیم (یا بسازیم) .

پس این طور نیست که وقتی ماهیت UI تغییر کنه ، به این دلیل باشه که Model مون تغییر میکنه . بلکه تغییر در Model مون بود که باعث تغییر در ماهیت UI مون شد .

از طرفی "تغییر در ظاهر (مثل تغییر در پوسته یا استایل یا template ئه) UI هم که اصلا باعث هیچ تغییری در Model نمیشه" .

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

SajjadKhati

کاربر فعال <A href="http://forum.majidonline.com/f
اگر عبارت "تغییر در x نتیجه تغییر در y هست." درست باشه باید با تغییر در y ناگزیر و حتمی x تغییر کنه چون این نتیجه همچین عملی بوده.
حالا یک مثال رو فرض کنید که شما یک User Interface دارید که یک متن رو از کاربر میگیره و با صدای مرد یا زن میخونه. در نسخه قبلی Model بر اساس یک تکنیک ابتدایی پایگاه داده اصوات از قبل ضبط شده طراحی شده که متن ورودی رو به صوت تبدیل می کرده و حالا در نسخه جدید به یک هوش مصنوعی با یک سرویس آنلاین تغییر کرده که متن ورودی رو به صوت تبدیل می کنه. در Model یک تغییر اساسی رخ داده، معماری بانک اطلاعاتی و منطق تجاری کلا تغییر کرده. اما واسط کاربری همچنان همونه که بود، اصلا تغییر نکرده. همچنان متن رو از کاربر میگیره و صوت حاصل رو پخش میکنه.

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

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

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

پس جمله ی زیر چطور؟ :

"تغییر در View نیست که باعث تغییر Model میشه" .

و "در کل ، تغییر View ، موضوعیت و محوریت نداره" .

به این معنا که اگه View مون تغییر کنه ، یا اصلا نیازی نیست که Model مون تغییر کنه یا اینکه با تغییر Model هست که ممکنه باعث تغییر در ماهیت View بشه .

بخش دوم پاراگراف بالا ، یعنی این طور نیست که چون ماهیت View مون تغییر کرد ، پس حالا حتما باید یه تغییری در Model مون بدیم . بلکه محوریت تغییری که اگه باعث تغییر در ماهیت View بشه ، با Model هست و با View نیست (ممکنه حتی ماهیت View تغییر کنه بدون اینکه Model تغییر کرده باشه که گفتید و در اینجا هم گفتم . که در این پاراگراف ، این قسمتش منظورم نیست) .
 
آخرین ویرایش:

the_king

مدیرکل انجمن
سلام
خیلی ممنون استاد .

پس جمله ی زیر چطور؟ :

"تغییر در View نیست که باعث تغییر Model میشه" .
گزاره ها یا قواعد الزام آور دارند که هر مثال نقضی نادرست شون میکنه یا الزام آور نیستند که چون قطعیتی ندارند مطرح کردن شون بی فایده است.
وقتی لایه ها استقلال دارند دنبال رابطه قطعی و الزام آور گشتن بی مورد ئه.
مثلا یک View دارید که برای کاربران فارسی زبان طراحی شده، حالا View رو ویرایش می کنید تا بین المللی و چند زبانه بشه، در نتیجه Model رو هم ویرایش می کنید تا داده هایی با تفکیک زبانی ارائه بده. پس تغییر در View میتوانست منجر به نیاز تغییرات در Model بشه، و چون قطعیت نداره مطرح کردن بیفایده است. دنبال رابطه قطعی و قاعده الزام آوری میگردید که نیست.
و "در کل ، تغییر View ، موضوعیت و محوریت نداره" .
شما یک واسط کاربری در نظر بگیرید که برای کاربر عادی طراحی شده، وقتی تغییر کنه تا برای کاربر نابینا یا ناشنوا قابل استفاده بشه یک تغییر موضوعی و محوری است.
به این معنا که اگه View مون تغییر کنه ، یا اصلا نیازی نیست که Model مون تغییر کنه یا اینکه با تغییر Model هست که ممکنه باعث تغییر در ماهیت View بشه .
اینها هیچکدوم قطعی نیستند.
 

جدیدترین ارسال ها

بالا