منتقل شده به اسمبلی System.Web.Webpages نگارش 2 آن.
۱۱ سال و ۸ ماه قبل، یکشنبه ۱۵ بهمن ۱۳۹۱، ساعت ۲۰:۱۵
۱۱ سال و ۸ ماه قبل، شنبه ۱۴ بهمن ۱۳۹۱، ساعت ۲۲:۰۹
آخرین تغییرات این مثال رو در اینجا می‌تونید مشاهده کنید. فقط در در آن PdfPTable تبدیل به PdfGrid شده.
۱۱ سال و ۸ ماه قبل، پنجشنبه ۱۲ بهمن ۱۳۹۱، ساعت ۲۱:۱۶
سلام؛ لطفا برای توضیحات بیشتر مراجعه کنید به قسمت 12 سری EF Code first. یک مثال کامل به همراه ارائه معماری قابل استفاده در MVC در آن مطرح شده است و کدهای آن نیز قابل دریافت است.
۱۱ سال و ۸ ماه قبل، پنجشنبه ۱۲ بهمن ۱۳۹۱، ساعت ۰۳:۳۶
من چیزی رو از فایل css آن حذف نکردم. فقط یک tahoma به اول تعاریف فونت‌های آن اضافه کردم.
به علاوه باید دقت داشت که تمام این ادیتورها در یک iframe بارگذاری می‌شوند. یعنی در حین نمایش، body آن‌ها تابع css خودشون است و نه css سایت. به همین جهت نیاز به کمی تغییر دارند:
به علاوه باید دقت داشت که تمام این ادیتورها در یک iframe بارگذاری می‌شوند. یعنی در حین نمایش، body آن‌ها تابع css خودشون است و نه css سایت. به همین جهت نیاز به کمی تغییر دارند:
body{
font-family:Tahoma,sans-serif;
font-size:9pt;
margin:0;padding:0;
overflow-x:hidden;
background:#fff;
direction:rtl
}
۱۱ سال و ۸ ماه قبل، پنجشنبه ۱۲ بهمن ۱۳۹۱، ساعت ۰۳:۱۲
خیر. احتمالا به این علت که آنچنان مرسوم نیست از چندین قلم در وب استفاده شود، منهای CSS اصلی سایت و تعریف قلم‌های اصلی برای هدرها و امثال آن. به علاوه قلم متن نمایش داده شده در صفحات باید تابع CSS سایت باشد نه ادیتور آن.
ولی در کل می‌تونید براش افزونه بنویسید تا اینکار را انجام دهد.
ولی در کل می‌تونید براش افزونه بنویسید تا اینکار را انجام دهد.
۱۱ سال و ۸ ماه قبل، سه‌شنبه ۱۰ بهمن ۱۳۹۱، ساعت ۱۳:۲۳
- لایه سرویس وابستگی به View نداره. هیچ ارجاع مستقیمی از عناصر بصری را در لایه سرویس نخواهید یافت. ViewModelها در MVC یک سری کلاس ساده دارای خاصیت ... خاصیت ... خاصیت بیشتر نیستید.
این سرویس ارائه شده چون با کلاس‌های مدل یا ViewModel ساده‌ای کار می‌کند که ارجاعی از عناصر بصری در آن نیست، در همه جا قابل استفاده است. چه View وجود داشته باشد یا خیر. کاملا مستقل از آن است و در نهایت View را تغذیه خواهد کرد؛ اما ارتباط یک طرفه است و نه دو طرفه.
عدم وابستگی به لایه بصری را در Web forms بهتر می‌شود توضیح داد. زمانیکه شما TextBox1.Text را در کدهای خود دارید، این به معنای وابستگی مستقیم است به عناصر بصری؛ نه حالتیکه یک کلاس ساده ViewModel دارای خاصیت ... خاصیت ... خاصیت را دارید که روح آن از وجود TextBox1 بی‌خبر است.
- در مورد بازگشت کلی domain model هم بحث شد؛ کمی بالاتر، خصوصا در گزارشات. این مساله سبب می‌شود که شما 20 فیلد را بازگشت داده و سپس در سمت کلاینت 3 مورد آن‌را نمایش دهید. به این ترتیب مصرف حافظه بالاتری را خواهید داشت. چون در ابتدای کار باید select تهیه شده در پشت صحنه هر چه هست و نیست را واکشی کند. سپس قصد دارید آن‌را به ViewModel نگاشت کنید. این نگاشت بهتر است همان ابتدای کار در select تهیه شده صورت گیرد؛ به این ترتیب واکشی از دیتابیس مثلا فقط به سه فیلد مورد نیاز محدود خواهد شد (با سرعت بیشتر و مصرف حافظه کمتر).
این سرویس ارائه شده چون با کلاس‌های مدل یا ViewModel ساده‌ای کار می‌کند که ارجاعی از عناصر بصری در آن نیست، در همه جا قابل استفاده است. چه View وجود داشته باشد یا خیر. کاملا مستقل از آن است و در نهایت View را تغذیه خواهد کرد؛ اما ارتباط یک طرفه است و نه دو طرفه.
عدم وابستگی به لایه بصری را در Web forms بهتر می‌شود توضیح داد. زمانیکه شما TextBox1.Text را در کدهای خود دارید، این به معنای وابستگی مستقیم است به عناصر بصری؛ نه حالتیکه یک کلاس ساده ViewModel دارای خاصیت ... خاصیت ... خاصیت را دارید که روح آن از وجود TextBox1 بی‌خبر است.
- در مورد بازگشت کلی domain model هم بحث شد؛ کمی بالاتر، خصوصا در گزارشات. این مساله سبب می‌شود که شما 20 فیلد را بازگشت داده و سپس در سمت کلاینت 3 مورد آن‌را نمایش دهید. به این ترتیب مصرف حافظه بالاتری را خواهید داشت. چون در ابتدای کار باید select تهیه شده در پشت صحنه هر چه هست و نیست را واکشی کند. سپس قصد دارید آن‌را به ViewModel نگاشت کنید. این نگاشت بهتر است همان ابتدای کار در select تهیه شده صورت گیرد؛ به این ترتیب واکشی از دیتابیس مثلا فقط به سه فیلد مورد نیاز محدود خواهد شد (با سرعت بیشتر و مصرف حافظه کمتر).
۱۱ سال و ۸ ماه قبل، سه‌شنبه ۱۰ بهمن ۱۳۹۱، ساعت ۰۲:۳۳
بله. لایه سرویس هم می‌تونه domain model بازگشت بده و هم view model. در عموم کارهای مایکروسافت این دو بجای هم بکار رفتن و یکی هستند. ما اینجا جداشون کردیم.
۱۱ سال و ۸ ماه قبل، دوشنبه ۹ بهمن ۱۳۹۱، ساعت ۲۲:۱۳
- بله. کار اصولی انجام دادن نیاز به کدنویسی بیشتری داره. اما در دراز مدت نگهداری ساده‌تری خواهد داشت چون حد و مرزها مشخص است و تغییرات سیستم جزئی‌تر خواهند بود با به هم ریختن حداقل قسمت‌های دیگر که به آن گره نخورده‌اند.
- ViewModel تغذیه کننده لایه UI است و نه اینکه با آن یکی باشد. اگر علاقمند هستید که وابستگی به UI رو بدونید مراجعه کنید به Web formها و جائیکه ارجاع مستقیمی از یک TextBox داخل کدهای برنامه (code behind) است. به این وابستگی می‌گن و نه حالت دیگری.
- در مورد محل قرارگیری Models و ViewModels در ابتدای متن فوق توضیح داده شده.
- ViewModel تغذیه کننده لایه UI است و نه اینکه با آن یکی باشد. اگر علاقمند هستید که وابستگی به UI رو بدونید مراجعه کنید به Web formها و جائیکه ارجاع مستقیمی از یک TextBox داخل کدهای برنامه (code behind) است. به این وابستگی می‌گن و نه حالت دیگری.
- در مورد محل قرارگیری Models و ViewModels در ابتدای متن فوق توضیح داده شده.
۱۱ سال و ۸ ماه قبل، دوشنبه ۹ بهمن ۱۳۹۱، ساعت ۲۱:۳۶
بله. به همین نحو طراحی شده. زمانیکه یک گزینه انتخاب می‌شود، سطر زیر، کاربر را به صفحه متناظر هدایت می‌کند:
این سطر در سمت کلاینت، مساوی Response.Redirect سمت سرور است. می‌تونید اینجا متن انتخابی رو به صورت مثلا یک کوئری استرینگ تعریف کنید و بعد در صفحه‌ای دیگر دریافت و نمایش بدید.
window.location = row[1];
۱۱ سال و ۸ ماه قبل، دوشنبه ۹ بهمن ۱۳۹۱، ساعت ۲۰:۰۸
لایه UI مصرف کننده است؛ تعیین کننده نیست و نباید حاوی منطقی بجز نمایش اطلاعات باشد. طراحی و بازگشت فیلدهای مورد نیاز باید در لایه سرویس به صورت مقید و واضحی انجام شود.