Служебни слоеве и хранилища - c #, модел-изглед-контролер, модел за хранилище, монорелсова крепост

Използвам MVC рамки за кратко времесега и наистина ми харесва как се разделят опасенията. Имам лош навик да оставям на контролерите да свършат доста работа. Така че наистина търся съвет.

Когато за първи път започнах да използвам MVC, много често имахконтролерът прави манипулация на моделите след като е била извършена работа с базата данни. Знаех, че това е лошо, така че се премести тази работа в моделите. Но аз не съм доволен от това, тъй като искам моите модели да се учат много.

Направих малко четене и виждам, че хората държат своите контролери и модели по-скромни, като имат слой, който ми харесва.

Аз просто се опитвам да разбера как един слой и хранилище трябва да работят заедно.

1. Контролерът може да извика директно хранилището, ако не е необходимо да се извършва манипулация на данните и като такъв слой на услугата не е необходимо да се включва
2. След като всяка работа трябва да се направи с данни (бизнес логика), то това трябва да се направи в сервизния слой и контролерът ще направи обикновен разговор със сервизния слой както и когато е необходимо
3. След като дадена услуга е направила бизнес логиката, тя ще използва хранилището, ако е необходимо (ако данните трябва да бъдат запазени).
4. Моделите в идеалния случай трябва да се поддържат сурови, в идеалния случай да се действа като нищо повече от DTO
5. Валидирането на данните ще се извършва в рамките на моделите(използвайки атрибутите за проверка на MonoRail). Оценявам, че дори не обича да замърсява техните модели с много атрибути, но това е различна дискусия. Харесва ми ползата от атрибутите за проверка на MonoRail за автоматичното валидиране на jQuery в потребителския интерфейс.

Опитвам се да обърна целия си код към принципа на единната отговорност, като по този начин се опитвам да оправя моите кодиращи практики.

Благодаря

Отговори:

Първо, няма набор от правила, които да се случватработа във всяка ситуация. Начинът, по който моделирате, е много зависим от вида и сложността на проекта.

1. Нищо не е наред с извикването на хранилището от контролер. Просто се уверете, че контролерът не съдържа бизнес логика.
2. Услугата се грижи за (някои) бизнес логика и използва други услуги за това. Хранилището е тип услуга, няма нищо лошо при извикването му от услуга.
3. Моделът Трябва съдържа бизнес логика, всъщност трябвавинаги се опитвайте първо да го поставите в модела. Ако имате нужда от външни данни, за да извършите тази бизнес логика (от друг модел или от хранилището), тогава трябва да създадете услуга.
4. Нищо не е наред с валидирането в моделите. Използването на атрибути или не е въпрос на вкус (ако ви харесва тогава е добре) Преместете валидирането извън модела, ако стане твърде сложно (създайте външни правила).

Най-важното е да правите онова, което се чувства правилно (това е обикновено правилният отговор).

Иън Купър току-що написа писмо на блога Дебел контролер само по тази тема.

Това видеото дава голяма представа за това как да се организираВашето решение за asp.net MVC и адресиране на разделението на притесненията и по-добра възможност за проверка. Надяваме се, че това също ще помогне на някой друг. Научих някои добри неща от него.