با سلام من نیاز دارم در layout سایتم مثلا منوها رو از بانک اطلاعاتی بخونم(اسمه _layout هست ودر پوشه shared قرار داره)
قبلا اینکارو از طریق از آجاکس میکردم
میخواستم ببینم راهه دیگه ای وجود داره؟چون موقعی در کنترلر مربوط به layout مثلا به نام _layout اکشنی رو براش مینویسم کار نمیکنه یا حتی کنترلی رو به نام shared ایجاد کردم بازم نشد
این روزها کلی اسکریپت های مبتنی بر jQuery هست که یک سری تگ <li> رو تبدیل به منو می کنند. در layout می توانید یک نمونه از کلاس dbContext تون بسازید و در یک حلقه foreach محتویات جدول مورد نظر رو تبدیل به یک سری تگ li کنید.
با تشکر
فکر کنم شما دقیق متوجه نشدید من چیکار میخوایم بکنم احتمالا من بد توضیح دادم
توی layout مثلا قراره یه بخش مثلا برای بنر تبلیغاتی داره یه بخش برای آخرین اخبار یه بخش هم برای مثلا جدیدترین محصولات که قراره توی تمام صفحات مشترک باشه
من اینکار رو اگر در layout نباشه تمام این موارد رو در viewmodel قرار میدم وبدون مشکلی میخونم
ولی زمانیکه قرار باشه تمام موارد بالا در layout باشه از آجاکس استفاده میکنم
حالا سوالم این بود که آیا میشه زمانی که از layout استفاده میکنیم میتونیم مثل روش استفاده بالا از viewmodel یا امکانات دیگه استفاده کنیم؟
اگر بله لطفا نمونه کد بذارید
یا اگر منظورمو درست متوجه شدید
لطفا نمونه پلاگینی که فرمودید رو نام ببرید
با تشکر از شما
شما باید از RenderAction در Layout_ استفاده کنی.
Html.RenderAction and Html.Action
فرض کنید اسم دیتابیس شما TestDb باشه، وقتی یک Entity Data Model برای اون دیتابیس می سازید اسم اون EDM معمولا میشه TestDbEntities. حالا در فایل layout اون بالا (خط اول) چنین دستوری رو اضافه کنید:
@{
var db = new TestDbEntities();
}
حالا در جایی در layout که می خواهید آخرین خبرها را نمایش بدید:
<ul>
@foreach(var item in db.News)
{
<li>
@item.NewsTitle
</li>
}
</ul>
به همین سادگی
بله به همین سادگی جواب داد!
من میومدم یه viewmodel میساختم مثل زیر
public class TestModel
{
public SelectList Client { get; set; }
public IEnumerable client()
{
using (var Context =new PerspolisEntities1())
{
var q = Context.Products;
return (q.ToList());
}
}
}
بعد مینوشتم @model IEnumerable<Perpolis_Leaft.Models.TestModel>
چون مثلا صفحه تماس با ما مدل مخصوص خودشو داره هی خطا میداد!
واقعا کارهای عجیبی میکردم!(قبلا که عجیب تر هم کار میکردم همه این بخش ها با جی کوئری و آجاکس میخوندم)
ممنون
همچین مثالی از شما دور از انتظاره جناب کرامتینوشته شده توسط مهدی کرامتی
فرض کنید اسم دیتابیس شما TestDb باشه، وقتی یک Entity Data Model برای اون دیتابیس می سازید اسم اون EDM معمولا میشه TestDbEntities. حالا در فایل layout اون بالا (خط اول) چنین دستوری رو اضافه کنید:
@{
var db = new TestDbEntities();
}
حالا در جایی در layout که می خواهید آخرین خبرها را نمایش بدید:
<ul>
@foreach(var item in db.News)
{
<li>
@item.NewsTitle
</li>
}
</ul>
به همین سادگی
چرا، مگه مشکلی داره؟
توابع استاتیک این جور وقتا به کار میان.کلا وقتی صحبت از ساختن یک بخش از صفحه در یک حلقه بر اساس چیزی که تو دیتابیس هستش میاد اسم یک کلاس به نام DropDownHelper به ذهن آدم میاد که این اسم همه جا همینه.تو این کلاس یک سری توابع استاتیک می سازید که براتون موارد رو از دیتابیس یا هر جای دیگه فراهم می کنن و محل اختصاصی استفاده از این توابع در Viewها هست.شما یک تابع در این کلاس مثلا با نام
public static List<News> GetNews()بسازید که یک لیستی از اخبار رو برای شما به ترتیب تاریخ return بکنه.بعد داخل View خودتون یه همچین چیزی رو پیاده کنید:
@foreach(var newsItem in yourprojectname.DropDownHelper.GetNews())
{
<li>@newsItem.Title</li>
}
اگه متوجه نشدید امر کنید مثال بذارم براتون.
آخرین ویرایش به وسیله younesdoost : سه شنبه 21 خرداد 1392 در 16:59 عصر
اگر امکانش هست یه مثال بزنید
با تشکر
اشکال که چه عرض کنم. به نظرتون اگه بیایم Controller رو نادیده بگیریم و مستقیما در View با EF کار کنیم کار درستی هست ؟ اینجوری که شما مثال زدین الگوی MVC شده MV.
خب.اول اینکه بگم که تمام اسمایی که من استفاده می کنم طبق قانون Naming Convention هستش که این یعنی همه جا به همین نام شناخته میشن.
توی پروژه ی UI خودتون یه فولدر به نام Components درست بکنید که توش کلاسایی مثلا مثل کلاسای زیر قرار می گیرن:
1-SessionContext (برای ایجاد Session برای Login به کار میره)
2-ObjectMapper (برای تبدیل مدل ها از Model به ViewModel و برعکس)
3-Utility (توش توابعی که زیاد استفاده میشن قرار میگیره.مثل DatePicker فارسی)
4-DropDownHelper (کلا توش توابعی قرار میگیرن که کاری که شما می خواید رو انجام میدن.البته توابع تبدیل Objectهای Name Value Pair مانند enum ها هم اینجا قرار میگیرن که ماهیت کار اونا هم با کار ما یکیه)
تمامی توابعی که توی کلاس DropDownHelper قرار میگیرن استاتیک هستند چون بیشتر توی View ها ازشون استفاده میشه.فرض کنید می خوایم داخل یک پروژه که نام Solution آن MyMVCApp و نام پروژه ای که داریم MyMVCApp.UI.Web هستش تیتر های خبرهای جدید رو از دیتابیس بخونیم و اونها رو توی Layout نشون بدیم.خب طبق اونچه گفتم فولدر مورد نظر و کلاس DropDownHelper رو تشکیل میدیم.بعد تابع زیر رو داخل کلاسمون ایجاد می کنیم:
حالا توی هر جا خواستید استفاده کنید مثل زیر استفاده کنید.مثلا تو Layout:
public static List<News> GetLatestNews()
}
var news=inja list akhbare jadidetoono az database bekhoonid
return news;
{
احتمالا زیر کلمه ی News خط کشیده شود که با Resolve کردن آن مشکل حل می شود.
از نامرتب بودن مطلبم هم عذر خواهی می کنم چون من عملا نمی تونم با text editor این سایت کار بکنم.
@foreach(var newsItem in MyMVCApp.MyMVCApp.UI.Web.Components.DropDownHelper .GetLatestNews(){
<li>
<a href="@Url.Action("Show","News",new{id=newsItem.Ne wsId})">@newsItem.Title</a>
<li/>
{
با سلام
مثال خوبی بود. متشکر.
من این کار رو می کردم. البته کمی سخت میشه...
یه کلاس پایه ای در نظر می گرفتم و کلا هر چیزی که در کل pageها ثابت بودند رو در این قرار میدادم.
بعد بقیه کلاس رو از این مشتق می گرفتم.
کلاس پایه:
public class ConstModels
{
public IEnumerable<MenuModel> MenuModels { set; get; }
public IEnumerable<FooterModel> FooterModels { set; get; }
}
public class HomePageViewModel : ConstModels
{
public IEnumerable<ManagerMessageModel> ManagerMessageModels { set; get; }
public IEnumerable<SliderModel> SliderModels { set; get; }
public IEnumerable<MainPageModel> MainPageModels { set; get; }
public IEnumerable<SiteNewsModel> SiteNewsModels { set; get; }
}
حالا واسه هر کدوم از کلاس های موجود در کلاس پایه یه PartialView می نوشتم و در Shared قرار می دادم.
مثل این:
@model DynamicWebsite.Models.ConstModels
@foreach (var item in Model.MenuModels)
{
<li>
...
</li>
}
سلام.
آره.من هم گاهی اوقات از این روش استفاده می کنم الان.مخصوصا وقتی که چیزایی که می خوام لود بکنم کم نباشن و برای خودشون یه جورایی یه بخش حساب بشن.مثلا برای جستجوی آژاکس که قرار نتیجه ی جستجو توی span قرار بگیره و قراره مثلا 5 ردیف چهار تایی از این span ها رو داشته باشیم دیگه اینو می برمش توی PartialView.اونوقت میشه خیلی راحت یه مدل رو به Partial خودمون پاس بدیم و بدون تابع استاتیکی مقادیرمون رو بخونیم.مطلب خوبی گذاشتید.ممنون.
می تونید خب توی کنترلر خودتون مقادیر رو داخل یه ViewBag بریزید و توی View از روی اون ViewBag حلقه رو بچرخید.
مگه توصیه نشده که از view bag کمتر استفاده کنیم و به جاش از view model استفاده کنیم؟
با تشکر از مطلب خوبتون
بله دوست خوبم.مطمئنا همینطوره.البته بستگی به اینکه شما می خواید چه کاری انجام بدید هم داره ها.اگه قرار باشه شما منوی خودتون رو بسازید که توابع استاتیک یا در سطح دوم استفاده از ViewBag یا در سطح آخر استفاده از ViewData جواب کار شما رو میده.اما حالا فرض کنید بخوایم یه ماتریسی بسازیم که تیتر سطراش اسم تولید کننده ها،تیتر ستوناش اسم مواد تولیدی و درایه هاش قیمتایی باشه که هر تولید کننده برای هر ماده میده.ساخت چنین چیزی هم ذاتا با کار ساخت منو یکیه ماهیتش اما با توابع استاتیک و ViewBag و ViewData محاله.یا اگه بشه 5 6 تا لازمه.اما این کار رو با یه ViewModel ساده میشه به راحتی انجام داد.این در حالیه که ساخت چنین ماتریسایی از کارهای نه چندان کوچیک برنامه نویسی به شمار میره.
میشه بگید که منظورتون از توابع استاتیک یا سطح دوم و سطح آخر چیه ؟
کار ViewBag, ViewData و TempData رد و بدل اطلاعات هست و همون ماتریسی که شما مثال زدید میشه با ViewBag یا ViewData به View منتقل کرد و نیازی به ٥ یا ٦ ViewBag یا ViewData نیست بلکه خود ماتریس میشه در ViewBag یا ViewData ذخیره کرد و به سمت View فرستاد و ظاهرا شما دلیل استفاده از ViewModel رو محدودیت در ارسال اطلاعات با ViewBag یا ViewData میدونید.
دلایل استفاده از ViewModel:
- ارسال بیش از یک Model به View
- اعتبار سنجی جداگانه ViewModel از Domain Model بر اساس آنچه در View لازم داریم
- حذف logic از View و فرمت بندی داده
- حذف ریسکهای امنیتی مانند مشکلی که در github به وجود اومد
- حذف وابستگی مستقیم بین لایەها
دوست عزیز اول اینکه منظور من از سطح اول و دوم یه جور نمره دادنه که اولویت اول رو با توابع استاتیک می دونم و اولویت دوم رو با ViewBag و اولویت سوم رو با VewData نه چیز دیگه.
دوم اینکه بنده دلیل خاصی رو از استفاده از ViewModel ذکر نکردم.اگه به تاپیک دقت کنید می بینید که همه ی حرفای من بر اساس تاپیک و مطلبیه که دوستمون گفتن و کلی حرف نزدم.
سوم اینکه مشخصه که شما هرگز یه همچین ماتریسی نساختی که هیچ حتی بهش فکرم نکرده که در مورد راه ساختش اینطوری فکر می کنی.یا شایدم اصن متوجه ماتریس نشدی.
چهارم اینکه توابع استاتیک رو بالا تو مثال من می تونید ببینید.(شاید این رو باید اول می گفتم اما حوصله ی اصلاح مطلبم رو ندارم
در آخرم هم از توضیحاتتون برای ViewModel تشکر می کنم گرچه جاش اینجا نبود.
در این ٤تا پست بحث سر الگوها و مفاهیم موجود در MVC بوده. ایرادی که من به آقای کرامتی گرفتم این بود که در View مستقیما با EF کار نشه چون کار View فقط نمایش اطلاعات هست و اینکه بیاییم html رو با logic قاطی کنیم کار درستی نیست و در این بین Controller حذف نشه که جواب شما این بوده که در Controller اطلاعات رو با استفاده از ViewBag به View بفرستیم.
حالا بحث سر اینکه که چرا در این مورد نباید از ViewBag یا ViewData استفاده بشه و توضیحی که من هم دادم در همین راستا بوده و رعایت Best Practiceهای موجود در MVC بوده است.
اما در مورد مثالی که زده بودین که تویه UI پوشه به نام Component ساخته بشه که شامل کلاسهایی میشه که زیاد استفاده میشن، تا جایی که من میدونم معمولا توی Solution پروژەای به نام Commen یا Infrastructure ساخته میشه که شامل کلاسها و توابعی میشه که توی لایەهای دیگه هم استفاده میشن و نه اینکه مختص در داخل لایە UI باشه. درضمن چه اینکه از این کلاس استاتیک شما و چه اینکه بصورت مستقیم از DbContext در View استفاده بشه ارتباط بین اجزا بصورت Loose coupling نیست و این یک اشکال طراحیه البته هر چند شاید برنامەهای که شما نوشتین به احتمال زیاد بیشتر از یک لایه نبوده و چیزی هم از این مفاهیم نمیدونید
در مورد ماتریس. یه جوری در مورد ماتریس حرف میزنید که انگار کرنل ویندوز نوشتین. یه سری هم به Tuple بزنید شاید این کار نچندان کوچیک رو براتون کوچیک کرد البته بدهم نیست یک بازنگری در مورد نحوه رابطه بین اجزاتون داشته باشین که مجبور نباشین برای ذخیره اطلاعات همچین موردی از ماتریس که کار نچندان کوچیکیه، استفاده کنین
دوست عزیز اول اینکه منظور من از سطح اول و دوم یه جور نمره دادنه که اولویت اول رو با توابع استاتیک می دونم و اولویت دوم رو با ViewBag و اولویت سوم رو با VewData نه چیز دیگه.
دوم اینکه بنده دلیل خاصی رو از استفاده از ViewModel ذکر نکردم.اگه به تاپیک دقت کنید می بینید که همه ی حرفای من بر اساس تاپیک و مطلبیه که دوستمون گفتن و کلی حرف نزدم.
سوم اینکه مشخصه که شما هرگز یه همچین ماتریسی نساختی که هیچ حتی بهش فکرم نکرده که در مورد راه ساختش اینطوری فکر می کنی.
چهارم اینکه توابع استاتیک رو بالا تو مثال من می تونید ببینید.(شاید این رو باید اول می گفتم اما حوصله ی اصلاح مطلبم رو ندارم
در آخرم هم از توضیحاتتون برای ViewModel تشکر می کنم گرچه جاش اینجا نبود..
دوست من لایه ی Infrastructure.Repository که شما ازش نام بردید شامل کلاسایی میشه که توش 4 عمل اصلی(CRUD) روی تک تک Entity های موجود نوشته میشه.البته در این لایه گاهی یک کلاس دیگه با نام Infrastructure هم ساخته میشه که توش توابع Memory Cache نوشته میشه.این لایه ی اول.در این ٤تا پست بحث سر الگوها و مفاهیم موجود در MVC بوده. ایرادی که من به آقای کرامتی گرفتم این بود که در View مستقیما با EF کار نشه چون کار View فقط نمایش اطلاعات هست و اینکه بیاییم html رو با logic قاطی کنیم کار درستی نیست و در این بین Controller حذف نشه که جواب شما این بوده که در Controller اطلاعات رو با استفاده از ViewBag به View بفرستیم.
حالا بحث سر اینکه که چرا در این مورد نباید از ViewBag یا ViewData استفاده بشه و توضیحی که من هم دادم در همین راستا بوده و رعایت Best Practiceهای موجود در MVC بوده است.
اما در مورد مثالی که زده بودین که تویه UI پوشه به نام Component ساخته بشه که شامل کلاسهایی میشه که زیاد استفاده میشن، تا جایی که من میدونم معمولا توی Solution پروژەای به نام Commen یا Infrastructure ساخته میشه که شامل کلاسها و توابعی میشه که توی لایەهای دیگه هم استفاده میشن و نه اینکه مختص در داخل لایە UI باشه. درضمن چه اینکه از این کلاس استاتیک شما و چه اینکه بصورت مستقیم از DbContext در View استفاده بشه ارتباط بین اجزا بصورت Loose coupling نیست و این یک اشکال طراحیه البته هر چند شاید برنامەهای که شما نوشتین به احتمال زیاد بیشتر از یک لایه نبوده و چیزی هم از این مفاهیم نمیدونید
در مورد ماتریس. یه جوری در مورد ماتریس حرف میزنید که انگار کرنل ویندوز نوشتین. یه سری هم به Tuple بزنید شاید این کار نچندان کوچیک رو براتون کوچیک کرد البته بدهم نیست یک بازنگری در مورد نحوه رابطه بین اجزاتون داشته باشین که مجبور نباشین برای ذخیره اطلاعات همچین موردی از ماتریس که کار نچندان کوچیکیه، استفاده کنین
لایه ی دوم لایه ی Application هستش که رابطی بین لایه ی Repository و UI هستش و همچنین بعضی کارای دیگه هم اینجا انجام میشه.
لایه ی بالا لایه ی UI هستش که لایه ی MVC هستش.مدل های این لایه که ViewModel هستن تبدیل میشن به مدل های اصلی که توی یه ClassLibrary جدا هستن تا کار رد و بدل اطلاعات بین لایه ها رو انجام بدن.
الیته تو Library مدلامون کلاسای Interface هم میسازیم که راحت بین CacheReporitory و Repository سوییچ بکنیم.یا هر مخزن دیگه.
به این میگن هنر MVC و نمیشه که کسی MVC کار بکنه و چند لایه برنامه نویسی رو بلد نباشه.پس همه بلدیم اینو.
بعدم اینکه من یادم نمیاد کسی جز خودم رو بی سواد فرض کرده باشم مگر اینکه خودش اصرار بکنه.
سوم اینکه تا سعی به نوشتن اون ماتریس نکنید میشید آدمی که بیرون گود نشسته و میگه لنگش کن چون به ظاهر کار ساده ایه و منم قبلش همین فکر رو می کردم.
چهارم اینکه اگه شما یکم ملایم تر صحبت می کردید،چه تو این پستای بالا چه قبلا، بنده از شکلک قهقه استفاده نمی کردم.بهر حال معذرت می خوام.
راستی من وقتی جوون بودم با VB6 که دوران خودش رو داشت DLL هم می نوشتم.
پاسخی که در آنجا دادم جهت تسهیل کار بود، وگرنه می توان یک Controller ایجاد کرد که آیتم های منو را در قالب یک Partial View بازگرداند، و با یک درخواست jQuery Ajax مقادیر فوق را دریافت کرده و در محل مورد نظر قرار داد، اما اگر این کار را انجام دهید می بینید که حجم کاری که باید برای رسیدن به همان هدف انجام داد بسیار بیشتر شده است. این در حالی است که کل منطق MVC و ابزارهای جانبی آن برای کاهش مدت زمان برنامه نویسی و حجم کاری که برنامه نویس باید انجام دهد طراحی شده است، بنابراین از نظر من گاهی اوقات استفاده از روش های میان بر ضرری ندارد.ایرادی که من به آقای کرامتی گرفتم این بود که در View مستقیما با EF کار نشه چون کار View فقط نمایش اطلاعات هست و اینکه بیاییم html رو با logic قاطی کنیم کار درستی نیست و در این بین Controller حذف نشه که جواب شما این بوده که در Controller اطلاعات رو با استفاده از ViewBag به View بفرستیم.
من که در هیچ یک از پستهام از Repository اسمی نبردم و تا جایی که من میدونم لایەای که اعمال CRUD در اون انجام میشه DataLayer بهش میگن. حالا از بحث نامگذاریها بگذریم چون یکم سلیقەای هست شاید من اسمش گذاشتم لایه هواپیما.
من فقط یک سئوال پرسیدم چون منظورتون رو از سطح یک یا دو نفهمیدم همین و ناملایمتی هم توی اون پستم نمیبینم.چهارم اینکه اگه شما یکم ملایم تر صحبت می کردید،چه تو این پستای بالا چه قبلا، بنده از شکلک قهقه استفاده نمی کردم.بهر حال معذرت می خوام.
بله یه زمانی کمودور 64 هم دوران خودش رو داشت.
بله جناب کرامتی من هم باشما موافقم استفاده از یک راه میانبر خوب هست ولی در این مورد کلا از هر نظر که بهش نگاه کنیم اشکال داره.
بالاخره نتیجه این پست چی شد؟ دوستان ماشالا... انقدر به حاشیه رفتند ما که گیج شدیم...
کدوم یک از پست ها میشه گفت بهترین جواب هست؟
شماره پست ها: 4 ، 5 ، 9 ، 13
لینکی که من تو پشت ٤ دادم از سایت Phil Haack هست که خودش جزو تیم ASP.NET MVC است و یکی از راههای درست پیاده سازیش همینه.
بله.از لایه ی Infrastructure نام بردید.Repository هم همونه.اون DataAccessLayer هم که میگید اسم قدیمیه همون Infrastructure.Repository هستش.الان تو سمپل های جدید خود مایکروسافت هم این اسما تغییر کردن.البته درسته که اسم سلیقه ایه ولی این دلیل نمیشه که از استانداردش پیروی نکنیم.چون پس فردا جایی بخوایم راجع به پروژه صحبت کنیم اول باید کلی اسمامونو توجیح کنیم.تازه اگه تیم یادشون بمونه.این استانداردا مخصوصا تو کارای تیمی اونم وقتی اعضای تیم تو جاهای مختلفی از دنیا باشن اصل اهمیت خودشون رو نشون می دن.ضمنا اون کلاسا که من گفتم زیاد استفاده میشن و میرن تو اون پوشه که بالا گفتم و شما گفتی منظور همون لایه ی Infrastructure هستش اینطور نیست.تو لایه ی Infrastructure صرفا CRUD انجام میشه و تو اون کلاسا که من گفتم مطلقا CRUD وجود نداره.منظور منم از سطح همونطور که گفتم اولویت بود.
همش درسته دوست من.بحث فقط سر پیچیدگی زمانیشه که آیا نیاز به استفاده از Controller هست یا نه.
البته بحثا انصافا حاشیه حاشیه هم نبودنا.حول و حوش تاپیک بودن.
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول