Когда использование МОК является соответствующим?
Я использовал это, потому что имя может быть частью файла-патча.
//http://support.microsoft.com/kb/177506
foreach(array('/','\\',':','*','?','<','>','|') as $char)
if(strpos($name,$char)!==false)
die("Not allowed char: '$char'");
5 ответов
Идея не в том, t для разрушения зависимостей между объектами домена, это защита вашего домена от внешнего мира. Объекты вашего домена должны относиться к любой бизнес-проблеме, которую вы решаете, а не к базам данных, журналированию, кешированию, контекстам http, службам отдыха и т. Д.
В этой статье рассказывается о перемещении ответственности из ваших объектов в контейнер IoC.
http://www.agileatwork.com/captcha-and-inversion-of-control/
Что ж, IOC не имеет большого смысла, если вы программируете очень конкретный компонент, который не будет иметь нескольких типов реализаций ...
Например; Допустим, вы программируете устройство чтения документов для своей компании и точно знаете, что бизнес-правило, стоящее за устройством чтения, заключается в том, что он никогда не будет читать документы любого другого типа, кроме документа MS Word. В этом случае ваши модульные тесты на самом деле не требуют слабой связи внедрения зависимостей, потому что компонент, который вы тестируете, никогда не будет зависеть от чего-либо, кроме документа MS Word. Использование контейнера IOC для определения типа считывателя может быть просто излишним.
Я думаю, что имеет смысл использовать его, когда вы знаете, что будете писать много модульных тестов, поскольку это облегчает создание этих тестов. Кроме того, он позволяет вам (через внешнюю конфигурацию) изменять поведение объектов во время выполнения.
Нет смысла использовать IoC в небольших проектах или проектах, которые не нуждаются в массивной развязке.
Я бы сказал, что это имеет наибольший смысл, когда вы знаете, что вам понадобится гибкое приложение, потому что требования будут часто меняться, или когда вы будете работать над большой системой с командой разработчиков. Это помогает при работе в команде, потому что вы можете работать над своей частью и позволить IoC позаботиться о ваших зависимостях.
Один из сценариев для IOC - это когда конкретное решение о реализации оспаривается командой разработчиков. IOC дает гибкость, позволяющую заменять реализации с минимальным трением. Это скорее тактическое соображение, чем что-либо еще.