ابهامات و پیشنهاد برای طراحی بهتر لایه بندی

[micro_bhk]

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

من تصمیم دارم از unit of work استفاده کنم. طبق پیش فرض لایه های زیر رو ایجاد کردم:

- Common
- Data Layer
- Domain Class
- Service Layer
- View Model
- Web.Mvc

یک سری سوال و ابهام برام ایجاد شده که شاید برای خیلی از دوستان پیش اومده باشه:

1- اینجا لایه BL کدم هست؟
توی کدوم لایه باید اعتبار داده ها، منطق سیستم مثل اعمال تخفیف، محاسبه کمیسیون و ... رو پیاده سازی کنم؟

2- به عنوان مثال من میخوام سیستم رو به صورت چند زبانه پیاده سازی کنم، در لایه View Model برای هر پروپرتی یه سری Custom Attribute مثل نام و پیغام اعتبار سنجی و ... نیاز هست تا برای هر زبان مقدارش از دیتابیس واکشی بشه (بحث کشینگ رعایت میشه).
به همین خاطر لایه View Model نیاز به رفرنس از لایه Service برای این کار داره، از طرفی خود Service برای متدهاش نیاز به لایه View Model داره که این کار امکان پذیر نیست و تو حلقه میفته.
برای رفع این حالت چه کاری میشه انجام داد؟


با تشکر

[hakim22]

1- لایه ی Domain یا Business Layer جایگاه یکسانی دارند. اینکه شما در حال استفاده از کدام هستید بستگی به نوع نگاه شما به مسئله دارد. وقتی شما با روش Domain کار میکنید یعنی نگاه شما از بالا به پایین است. شما یک مفهوم کلی را در نظر میگیرید و کم کم آن را به بخشهای مجزا و کوچکتر تقسیم میکنید. مثل اینکه بگید من میخواهم یک سایت فروشگاهی بسازم. فروشگاه شامل چه بخشهایی میشود. چه قسمتهایی لازم دارم. ... که یعنی شما از بالا به پایین همه ی جزئیات را پلن میکنید و تا حد ممکن سعی میکنید یک مسئله ی بزرگ را به اجزای کوچک و قابل پیاده سازی تبدیل کنید. هر بخش را به صورت یک ماژول به درون دامنه اضافه می کنید.

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

در نهایت این نامها انتخابی است و ممکن است پروژه ی شما به شکل دیگری تقسیم بندی شود. انتخاب آن با شماست. هیچ روش صد در صد و استانداردی برای تقسیم بندی پروژه وجود ندارد.


2 - راه ساده این است که آن بخشهایی که میخواهید از لایه ی سرویس جدا کنید و در یک پروژه ی دیگر قرار دهید به نحوی که هر دو پروژه بتوانند به آن Refrence دهند. وحی برای اینکار نازل نشده که حتما باید در یک پروژه با نام Service قرار بگیرند.

نکته ی دیگر با توجه به اینکه شما قرار است از Entity framework استفاده کنید دیگر لایه ای به نام Data Layer ندارید. خود EF این لایه را شامل میشود. و خود این سیستم دارای Unit Of work هست و اینکه شما برای کارتان میخواهید از UoW استفاده کند به این شیوده درست نیست. به نظر میرسد که شما در حال پیاده سازی پروژه به نحوی هستید که با این مدل کار کند. در حالی که شما اول باید پروژه را پیاده کنید و بعد بر اساس نیازها اگر لازم شد UoW را مورد استفاده قرار دهید. من هیچ دلیلی برای استفاده از این تکنیک پروژه نمی بینم. و عملا بسیار کم مورد نیاز است.

در آخر اینکه پیشنهاد من این است که شما فقط از دو پروژه استفاده کنید. یک پروژه برای وب و MVC و یک پروژه هم برای سایر چیزها و آنها را با Folder بندی جدا کنید. حتی در پروژههای بزرگ و تیمی هم این رشو خیلی خیلی بهتر جواب میدهد و نیازی به اینکه چندین پروژه در یک Solution بسازید وجود ندارد.

[micro_bhk]

با تشکر از پاسختون

حقیقتش با توجه به نیاز پروژه من از سری آموزشی Unit of Work آقای نصیری در پروژم استفاده کردم بخاطر اینکه در خیلی از درخواست های کاربر ممکنه چند تا جدول ویرایش و... بشن.

با توجه به اون معماری نظرتون چیه؟

پروژه ای که در حال انجام هست بزرگه و نسخه موبایل هم خواهد داشت.

[hakim22]

اگر شما از مدل Repository/Service استفاده می کنید نیاز به پیاده سازی بخشی به عنوان Unit Of Work دارید. به این دلیل که Repository جداول را از هم جدا می کند و بعد کار کردن با چند جدول کنار هم (مثلا در یک تراکنش) نا ممکن میشود . شما می توانید از لایه ی Repository استفاده نکنید و نیازی هم به UoW نخواهید داشت.

بعضی چیزها در تئوری خیلی جذاب هستند. اما در عمل پیاده کردن آنها نه تنها ساده نیست ، هیچ سودی هم برای شما ندارد. اگر شما تنهایی و یا در یک تیم کوچک و متوسط در حال کار هستید نیازی به پیاده سازی چنین مدلی ندارید. فرقی نمیکند پروژه ی شما چند جدول داشته باشد. تعداد جدول ها هیچ ارتباطی با Unit Of Work ندارد.

الگوهای طراحی در برنامه نویسی کم نیست و شما نمی توانید همه ی آنها را در پروژه پیاده کنید و نباید هم پروژه را بر اساس یکی از آنها پیاده کنید.

به الگوها مانند یک ابزار کار نگاه کنید نه هدف پروژه.