Този подход към модела контролер с ниско съдържание на мазнини отива твърде далеч
Страхувам се, че може да съм мързелив.
Разработихме приложение за рубин релси, което включва около 8 модела за два типа потребители: лекари и пациенти. По-голямата част от логиката е вътре в моделите, които позволяват действието на контролера ми да бъде много кратко и кратко. Освен това тестването е съвсем просто.
В момента виждам поне две контроли и тестовете, които пиша, ме карат да вярвам, че повечето от функциите ми, с които потребителите се сблъскват, могат да се управляват от тези два контролера. Разбира се, мога да разбия това на по-чувствителни отделения - като тестове за пациент-контролер, лекар-контролер, лекар-пациент-контролер, пациент-лаборатория-резултати-контролер и т.н. Но ми се струва, че единственото предимство тук е по-дискретната организация.
На въпроса, освен разделянето, какви са причините да не се използва възможно най-малко контролери, да ги опаковате с много действия [недостатък], но да поддържате действията тънки [предимство]? Или . стигнете до крайност: защо не и с MVC, имате много мазни модели и слаб контролер [макар и дълъг], а не пациент контролер/модел/мнения + тестове за всеки, лекар контролер/модел/мнения + тестове за всеки и т.н.?
3 отговора
Има организация, защото всичко, което прави един контролер, е възможно, ще бъде по-трудно да се разбере и промени. Вместо да можете да отворите файл в редактора си и веднага да намерите действието, което търсите, превъртете файла, за да намерите това, което търсите.
Това също води до модела Обект на Бог в която всичко се случва в един обект, който е отговорен за всичко и всеки, който работи по проекта, ще промени същия обект, което води до стар ад на сливане.
И на самия Rails има RESTfulness на рамката. Rails възприема идеята да бъдете RESTful и един от стълбовете на тази идея са ресурси и те могат лесно да бъдат организирани само в отделни контролери. Ако се опитате да поставите два различни ресурса на един и същ контролер, вероятно ще се окажете с луди маршрути или луд логически контролер, за да разберете кой модел е представен.
Ако смятате, че вашите драйвери имат много повтарящи се кодове, можете да ги премахнете, като използвате няколко метапрограми или конвенции, но дори е по-добре да ги разделите, не само за организация, но и за опростяване на бъдещата ви поддръжка.
На този въпрос е невъзможно да се отговори. Контролерите са свързани с маршрути и потребителски взаимодействия и визии, а не с бизнес логика. Имате толкова контролери и действия, колкото има смисъл за вашите връзки и мнения.!
Ако вашата бизнес логика е изцяло във вашите модели, тогава това е достатъчно просто. Основната трудност с логиката в контролерите е, че не можете да използвате повторно логиката.
Няма какво друго да кажа. От вас зависи да направите това, което има смисъл във вашето приложение, например. имате контролер за търсене, за да търсите неща, вместо да добавяте действие за търсене към съществуващите си контролери, всъщност не е нищо повече от отделяне и яснота
Ако има много обща логика на контролера, препоръчваме ви да го извлечете в плъгин или как можете да го смесите, когато е необходимо. Или контролите биха могли да наследят от общ базов контролер (точно както всички контролери наследяват от ApplicationController по подразбиране, вместо от ActionController: Base).
Бих ви посъветвал да нямате гигантски контролер; контролерът трябва да управлява набора от действия, свързани с един вид ресурс (или най-близкия възможен аналог). Тази идея е още по-силна, ако се опитате да създадете RESTful дизайн, при който всеки контролер обикновено няма нищо друго освен седемте основни действия (индексиране, представяне, създаване, редактиране, актуализиране, унищожаване).
Така че, ако искате да имате URL адреси като/Patients/52394802/lab_results, мисля, че е разумно да имате LabResultsController. Ако тези контроли са лесни, прекрасни. Вярвам, че съществуването им все още е оправдано. Това няма да ви попречи да се опитате да получите своя СУХИ код; по-скоро бих се опитал да злоупотребя с общата функционалност по различен начин.