ساختار پروژه

[avagroup_dev]

با سلام خدمت دوستان

میخواستم در مورد ساختار پروژه ای که شامل بخش مدیریت، نمایش عموم و بخش کاربران (web Api) هست سوالی بپرسم.

- به نظرتون بهتر نیست هر کدوم از بخش هارو توی زیر دامنه های مخصوص خودشون بذارم که به نوعی هر قسمت شامل یه پرژه جدا بشه: مثلا
ترجیح من اینه برای امنیت بیشتر قسمت ادمین رو کاملا جدای از بخش های عمومی قرار بدم.

www.mysite.com (http://www.mysite.com)
admin.mysite.com
api.mysite.com

هم از لحاظ کد نویسی بخش ها جدا میشه و هم توی فاز عملیاتیش.

- یه موردی که ایجاد میشه بحث های کش کردنه اطلاعاته، (من از EF به صورت Code First استفاده میکنم از روش UOW)
چون هر کدوم از پروژه ها توی بخش مجزا و زیر دامنه های مجزا هستن، چطور میشه بحث کشینگ رو مدیریت کرد. (به ذهنم رسیده که از Redis استفاده کنم واسه یه سری دیتای پر استفاده)

- به نظرتوت ممکنه به چه مشکلاتی توی این حالت ها بخورم


لطفا نظرات و پیشنهادات خودتون رو در رابطه با این بحث برای آشنایی بهتر خودم و بقیه دوستان ارائه بدید

با تشکر

[hakim22]

این کار فقط در پروژه های خیلی بزرگ کارایی داره. برای 80 درصد پروژه ها یک کار اضافی است. دردسر مدیریت چنین پروژه ای خیلی بیشتر از پروژه ی یکپارچه است.
مخصوصا اگه تنها کار میکنید یا درون یک تیم کاری کوچک مشغول به کار هستید. این سبک پروژه برای تیمها بزرگ که هر تیم مسئول یک بخش خاص میشود کارایی دارد.

از مزایای این روش آپدیت یک سایت بدون نیاز به آپدیت سایر سایتهاست. مثلا ممکن است شما تغییرات زیادی در پروژه ی Admin ایجاد کنید. با توجه به اینکه دسترسی به این پروژه محدود است و افراد کمی با آن کار می کنند میتوانید آن را به صورت مجزا آپدیت کنید و خیالتان راحت باشد که پروژه ی اصلی با مشکل روبرو نخواهد شد. اگر هم در آپدیت باگی باشد فقط مربوط به Admin میشود.

همینطور برای وب سرویس (Web Api)هم همین قضیه صادق است. با توجه به اینکه کلاسهای WebApi از کلاسهای MVC جدا هستند جدا کردن پروژه کمک میکند بدون مشکل آپدیت مجزا صورت گیرد.

یکی از چالشهای شما در این روش مدیریت دسترسی ها بین چند دامنه است. اگر یک کاربر به یکی از سایتها وارد شد باید در همه ی سایتها ورودش قابل مشاهده باشد.

به نظر من در شروع پروژه وارد این جزئیات شدن بی مورد است. شما هر زمان که لازم باشد میتوانید جدا سازی را در پروژه اعمال کنید. مجبور نیستید از همان اول تصمیم بگیرید.
اگر ساختار پروژه ی شما بر مبنای اصول جدا سازی Separation Of Concerns بنا شده باشد جدا کردن یک Area از پروژ اصلی و تبدیل آن به یک پروژه ی جدید زیاد وقت نمیبرد.
ممکن است پروژه ی شما آنقدر بزرگ نشود یا چنین نیاز در عمل پیش نیاید . برای هر کدا از قسمتهای جدا یک Area درست کنید و چنانچه لازم شد بعدا آن را تبدیل به پروژه ی مجزا و زیر دامنه ی جدا کنید.