وحید نصیری وحید نصیری
نظرات مطالب
راهنمای آموزشی رایگان entity framework
تمرکز اصلی نگارش بعدی EF روی روش Code first است و فعلا باید منتظر باشید تا با یک فریم ورک پخته مواجه شوید. در حال حاضر (مطابق تاریخ نگارش این مطلب) روش database first در EF ارجح است (و پخته) و اگر اصرار دارید که حتما code first کار کنید به NHibernate مهاجرت کنید.
برای لایه بندی با هر ORM ایی که کار می‌کنید (فرقی نمی‌کند که چه نامی دارد)، باید از الگوی Repository استفاده کنید (یک مطلب در این مورد در سایت هست). این مورد چند مزیت دارد:
- کد شما به یک ORM خاص وابسته نمی‌شود.
- چون از اینترفیس برای تعریف Repository استفاده می‌شود راحت می‌شود برای آن Mock نوشت و راحت Unit testing را روی آن پیاده سازی کرد؛ با توجه به اینکه در Unit test نباید از مرزهای برنامه خارج شد و اگر خارج شدید این نوع آزمایشات Integration test نام دارند و نه Unit test . با Mocking یک repository می‌شود دیتابیسی را در حافظه تشکیل داد و تست کرد.
- در این حالت DAL همان ORM شما است. Repository همان BLL خواهد بود و برای جدا سازی کدها از لایه نمایشی از یکی از الگوهای MVVM یا MVC یا MVP استفاده کنید.

برای به روز رسانی هم در روش database first بهتر است هر آنچه که در فایل edmx شما است حذف کنید و بعد مجددا ایجاد کنید. به این صورت مشکلات به روز رسانی مدل را اصلا نخواهید داشت.
در حالت‌های دیگر هم امکان تهیه اسکریپت پیش بینی شده. شما می‌تونید بر اساس اسکریپت تولیدی بانک اطلاعاتی را به روز کنید.
‫۱۳ سال و ۱۲ ماه قبل، پنجشنبه ۱۱ آذر ۱۳۸۹، ساعت ۱۳:۵۷
علی ملکیان علی ملکیان
پاسخ به بازخورد‌های پروژه‌ها
توضیحاتی در مورد سیستم Identity پروژه
ممنون بابت پاسختون.

در این مورد که فرمودید

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

و در این مورد :

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


کل مجوز‌ها : A و B و C و D و E و ...

گروه 1 با مجوزهای A و B
گروه 2 با مجوز‌های B و C
( مجوز B بین هر دو مشترکه )
حالا مدیر ارشد میخواد گروهی تشکیل بده که به مجوز A و C نیاز داره. برای این کار بهتره که یک گروه 3 ایجاد کنه که مجوز‌های A و C روداشته باشه. ( دقیقا چیزی که فرمودید یعنی ساخت گروه هایی که نقطه مشترکی ندارن )
حالا شرایطی رخ میده که مدیر ارشد میخواد گروهی تشکیل بده که به مجوز‌های A و B و C نیاز داشته باشه. به نظرتون باید گروه 1 و گروه 2 رو به کاربران مورد نظر اختصاص بده یا اینکه فرضا یک گروه تشکل بده که این 3 مجوز رو داشته باشن و این گروهرو به کاربران اختصاص بده ؟
با توجه به سیستم طراحی شده شما ، مدیر ارشد میتونه هر دو روش رو طوری که دوست داره پیاده سازی بکنه. که یا یک گروه جدید بسازه یا اینکه هر دو گروه رو به کاربر بده. که این پویا بودن کار رو نشون میده ولی یک سوال برای من پیش اومده اونم اینه که فرض کنید مدیر ارشد گروه 1 و گروه 2 رو به یک کاربر اختصاص بده حالا بعد از مدتی میخواد مجوز B رو از این کاربر بگیرن. با این شرایط باز هم مجبورن از هر دو گروه صرفه نظر کنن چون هر دو گروه مجوز B رو دارن.
در کل هدف من اینه اگر فقط اجازه انتخاب یک نقش برای کاربر رو بدیم آیا این روش مناسب هست یا خیر ( منظورم اینه برنامه نویس اجازه بده مدیران ارشد فقط یک نقش به کاربر بدن و نه چند نقش) ؟ چون اگر این کارو بکنیم باز هم مدیر ارشد میتونه هرکاری که دوست داره بکنه و گروه‌های زیادی برای خودش اونطوری که دوست داره بسازه با مجوز‌های مختلف و به کاربران خاصی نقش‌های خاصی بده و در کل جلوی چند نقش دادن به یک کاربر رو بگیریم.
‫۸ سال و ۱۱ ماه قبل، شنبه ۳۰ آبان ۱۳۹۴، ساعت ۰۵:۲۵