Овој пристап кон моделот на контролор со малку маснотии оди предалеку
Се плашам дека може да бидам мрзлива.
Развивме апликација рубинска шина, која вклучува околу 8 модели за два вида корисници: лекари и пациенти. Најголемиот дел од логиката е во моделите што овозможуваат моето дејство на контролорот да биде многу кратко и концизно. Покрај тоа, тоа го прави тестирањето прилично едноставно.
Во моментов, гледам најмалку две контроли и тестовите што ги пишувам ме наведуваат да верувам дека повеќето од моите карактеристики со кои се соочуваат корисниците можат да бидат управувани од овие два контролори. Секако, ова можам да го разградам на почувствителни оддели - како што се тестови за контролор на пациент, контролор на лекар, лек за контролор на пациент, контролер за резултати од лабораторија за пациенти итн. Но, ми се чини дека единствената предност тука е подискретната организација.
На прашањето, освен одделението, кои се причините за да не се користат што е можно помалку контролери, спакувајте ги со многу дејства [неповолна положба], но задржете ги активностите тенки [предност]? Или однесете го до крајност: зошто да не со MVC, имате многу масни модели и слаб контролер [иако долг] отколку контролор/модел/мислења за пациенти + тестови за секој, контролер/модел/мислења за доктор + тестови за секој, итн?
3 одговори
Постои организација, бидејќи сè што прави еден контролор е можно, ќе биде потешко да се разбере и промени. Наместо да можете да отворите датотека во уредникот и веднаш да го пронајдете дејството што го барате, скролувајте по датотеката за да го пронајдете она што го барате.
Ова исто така води кон моделот Божји предмет во кој сè се случува во рамките на еден единствен објект што е одговорен за сè и секој што работи на проектот ќе го смени истиот објект, што ќе доведе до стар пекол на спојување.
И, на самите шини, има одмор во рамката. Пругите ја прифаќаат идејата да бидат РЕСТЛИВИ и еден од столбовите на оваа идеја се ресурсите и тие можат лесно да се организираат само во посебни контролери. Ако се обидете да поставите два различни ресурси на ист контролер, најверојатно ќе завршите со луди правци или луд логички контролер за да откриете кој модел е претставен.
Ако мислите дека вашите возачи имаат многу повторен код, можете да ги отстраните користејќи неколку мета-програми или конвенции, но уште подобро е да ги одделите, не само за организација, туку и за поедноставување на идното одржување.
Ова е невозможно прашање да се одговори. Контролорите се однесуваат на рути и интеракции и визии на корисниците, а не деловна логика. Имате онолку контролори и активности колку што има смисла да имате за вашите врски и мислења.!
Ако вашата деловна логика е сè во вашите модели, тогаш таа е доволно едноставна. Главната тешкотија со логиката кај контролорите е тоа што не можете повторно да ја користите логиката.
Ништо друго да се каже. Од вас зависи дали ќе направите што има смисла во вашата апликација на пример. имате контролер за пребарување за да пребарувате работи, наместо да додавате дејство за пребарување на вашите постоечки контролери, не значи ништо повеќе од одвојување и јасност
Ако има многу заедничка логика на контролорот, препорачуваме да го извлечете во приклучок или како да го измешате кога е потребно. Или контролите можат да наследат од заеднички контролен контролер (исто како што сите контролери стандардно наследуваат од ApplicationController, наместо ActionController: Base).
Јас би ве советувал да немате гигантски контролер; контролорот треба да управува со множеството активности што се однесуваат на еден вид ресурси (или најблискиот можен аналог). Оваа идеја е уште посилна ако се обидете да креирате РЕСОЛНИ дизајн, во кој секој контролер обично нема ништо освен седумте основни дејства (индексирање, презентирање, креирање, уредување, ажурирање, уништување).
Значи, ако сакате да имате URL-адреси како/пациенти/52394802/лаб_резултати, мислам дека е чувствителност да имате LabResultsController. Ако овие контроли се лесни, прекрасно. Верувам дека нивното постоење е сè уште оправдано. Ова нема да ве спречи да се обидете да го добиете вашиот сув код; наместо тоа, би се обидел да ја злоупотребувам заедничката функционалност поинаку.