مهمان مهمان
نظرات مطالب
AngularJS #2
1- منطق برنامه در Razor نوشته نمیشود ، بلکه در کلاسها و توابع پیاده سازی شده است.
2-سایت بدون data به درد کسی نمیخورد.(مثلا جی میل که به کدهای سمت کلاینت(html,js,...) دسترسی وجود دارد)
3-بهتر است بار تولید UI سمت کلاینت باشد تا سرور.در سمت سرور باید فقط data رد و بدل شود.
‫۱۱ سال و ۲ ماه قبل، یکشنبه ۱۰ شهریور ۱۳۹۲، ساعت ۱۷:۰۱
مهمان مهمان
نظرات مطالب
تزریق وابستگی (Dependency Injection) و توسعه پذیری
با سلام و عرض خسته نباشید
آیا در همه جای پروژه باید ازاین روش استفاده کرد.منظورم استفاده از یک DI Container‌ است.آیا anti-pattern ای در این مورد هم وجود دارد؟مثلا من یک پروژه‌ی ماژوالار بزرگ دارم آیا فقط در قسمت اتصال کلاس‌ها به لایه‌ی UI یا همون MVC از DI Container استفاده کنم یا هیج جای پروژه ام new() نداشته باشم و همیشه از DI Container اسم کلاسم رو بگیرم؟ با توجه به بزرگی پروژه ام آیا Performance از دست نمیدم؟
‫۱۱ سال و ۴ ماه قبل، شنبه ۱۵ تیر ۱۳۹۲، ساعت ۱۶:۵۰
محسن خان محسن خان
نظرات مطالب
MVC vs 3-Tier Pattern
همون لایه UI هم نیاز به جداسازی کدهای نمایشی از کدهای مدیریت کننده آن برای بالابردن امکان آزمایش کردن و یا حتی استفاده مجدد قسمت‌های مختلف اون داره. در این حالت شما راحت نمی‌تونید MVC و Web forms رو در یک سطح قرار بدی (که اگر اینطور بود اصلا نیازی به MVC نبود؛ نیازی به MVVM برای سیلورلایت یا WPF نبود و یا نیازی به MVP برای WinForms یا Web forms نبود).
‫۱۱ سال و ۵ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۳:۱۹
مهرداد اشکانی مهرداد اشکانی
نظرات مطالب
MVC vs 3-Tier Pattern
لایه business Logic  در واقع لایه پیاده سازی Business پروژه شما می‌باشد با یک مثال عرض می‌کنم فرض کنید در لایه UI شما لازم دارید یک گزارش از لیست مشتریانی که بالاترین خرید را در 6 ماه گذشته داشته اند و لیست تراکنش مالی آنها را بدست آورید.برای این مورد شما توسط کلاسهای و متدهای لازم ، در لایه Business Logic  این عملیات را پیاده سازی می‌کنید.
‫۱۱ سال و ۵ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۱۳:۴۸
محسن اسماعیل پور محسن اسماعیل پور
نظرات مطالب
MVC vs 3-Tier Pattern
3-Layer در واقع Architecture Style هست اما MVC یک Design Pattern هست پس مقایسه مستقیم نمیدونم کاری دست باشد یا نه اما میتونیم به این شکل نتیجه گیری کنیم:
Data Access: شامل کلاسهای ADO.NET یا EF برای کار با دیتابیس.
Business Logic: یا همان Domain logic که میتوان Model رو به عنوان  Business entity در این لایه بکار برد.
UI Layer: بکارگیری Controller و View در این لایه

‫۱۱ سال و ۵ ماه قبل، دوشنبه ۲۷ خرداد ۱۳۹۲، ساعت ۰۳:۰۳
میثم خوشبخت میثم خوشبخت
نظرات مطالب
معماری لایه بندی نرم افزار #1
با تشکر از دوست عزیزم جناب آقای آرمان فرقانی با توضیحی که دادند.
یکی از دلایل این شیوه کد نویسی امکان تست نویسی برای هر یک از لایه‌ها و همچنین استقلال لایه‌ها از هم دیگه هست که هر لایه بتونه بدون وجود لایه‌ی دیگه تست بشه. ماژولار کردنه ممکنه مشکل Smart UI رو حل کنه و ممکنه حل نکنه. بستگی به شیوه کد نویسی داره.
‫۱۱ سال و ۸ ماه قبل، سه‌شنبه ۲۹ اسفند ۱۳۹۱، ساعت ۱۶:۰۸
مهمان مهمان
نظرات مطالب
چک لیست تهیه یک برنامه ASP.NET MVC
با سلام
خیر  ، فکر نمیکتم کار درستی باشد . لایه سرویس خود باید به صورت لایه ای مجزا باشد
باید توجه داشته باشیم که ما میتوانیم تمام کلاس‌های سرویس ، DomainClasses  و ... را در همان پروژه اصلی داشته باشیم(منظور همان پروژهای است که UI درون آن میباشد) ولی اگر بخواهیم در آینده آن را گسترش دهیم ، با حجم عظیمی از کد‌ها و کلاس‌ها مواجه هستم . پس بهتر است تمامی قسمت‌ها به صورت مجزا (در لایه‌های مجزا) تعریف شود
‫۱۱ سال و ۹ ماه قبل، جمعه ۲۷ بهمن ۱۳۹۱، ساعت ۲۳:۳۹
کیارش سلیمان زاده کیارش سلیمان زاده
نظرات مطالب
چک لیست تهیه یک برنامه ASP.NET MVC
فرض کنید که در UI فقط به نام کاربر و آدرس ایمیل کاربر احتیاج است،کلاس کاربر در در Domain به شرح زیر است:
public class User
{
   public int UserId {get;set;}
   public string Name {get;set;}
   public string Family {get;set;}
   public string Web {get;set;}
   public string Email {get;set;}
   public DateTime RegisterDate {get;set;}
}
حالا در یک کنترلر فقط به نام کاربر و آدرس ایمیل کاربر احتیاج است،حالا میایم یک کلاس تعریف میکنیم که شامل فیلدهای مورد نیاز است:
public class UserInfoViewModel
{
   public string Name {get;set;}
   public string Family {get;set;}
   public string Email {get;set;}
}
و لایه سرویس یک متد منحصر بفرد مختص این کار می نویسیم ،مثلاً:
public UserInfoViewModel GetMemberByUserName(string username)
{
   var result = from u in _users
                   where u.UserName == username
                   select new UserInfoViewModel() {Name = u.Name,Family=u.Family,Email=u.Email};

   return result;
}
1-اگه این روش درسته،حالا:
  • - برای هر متد که نیازه یه سری فیلد مورد نیاز رو برگردونه،یه کلاس جداگانه باید تعریف کرد؟(در اینجا UserInfoViewModel)؟
  • - این کلاس UserInfoViewModel باید جز ViewModel‌های لایه UI باشه و در لایه Models قرار بگیره؟
      در اینصورت (کلاس UserInfoViewModel باید جز ViewModel‌های لایه UI باشه )،لایه سرویس   وابسته به لایه UI نمیشه؟
      اگر جواب منفیه،
      کلاس UserInfoViewModel تو کدوم لایه باید قرار بگیره؟
      دیگه نباید پسوند ViewModel رو به این کلاس اضافه کرد،درسته؟
2-اگه این روش کلاً اشتباهه،راه حل شما دقیقاً چیه؟
‫۱۱ سال و ۹ ماه قبل، دوشنبه ۹ بهمن ۱۳۹۱، ساعت ۲۱:۳۹
مهمان مهمان
نظرات مطالب
EF Code First #12
سلام. من توی برنامه WPF MVVM ای که نوشتم یه Context توی هر ViewModel ایجاد می‌کنم میکنم و در پایان توی بستن ویومدل Context رو Dispose می‌کنم. قبلاً از using برای مدیریت اتصال به دیتابیس استفاده می‌کردم ولی وقتی از using استفاده می‌کنم دیگه تغییراتی که اعمال می‌کنم (حذف، ویرایش، افزودن) UI متوجه نمیشه.
میخواستم بدونم این مشکل با استفاده از الگوی Context Per Request حل میشه یا نه؟
‫۱۱ سال و ۱۰ ماه قبل، جمعه ۲۹ دی ۱۳۹۱، ساعت ۱۲:۵۷
وحید نصیری وحید نصیری
نظرات مطالب
آشنایی با الگوی M-V-VM‌ - قسمت پنجم
دو نوع کلاس اینجا وجود دارند:
domain models : کلاس‌های معادل جداول و موجودیت‌های بانک اطلاعاتی
viewmodels : مقصود از این viewmodelها، کلاس مدل معادل عناصر بصری UI است و منظور viewmodel تعریف شده در MVVM نیست که دقیقا معادل Controller در MVC است.
بنابراین اگر domain model شما با مدل معادل view یکی است، همه رو یکجا هم می‌تونید تعریف کنید ولی عموما این‌ها یکی نیستند. بنابراین نیاز است بین این دو فرق گذاشت و در صورت نیاز نگاشت لازم را انجام داد.
‫۱۲ سال و ۱ ماه قبل، شنبه ۸ مهر ۱۳۹۱، ساعت ۱۵:۲۶