Да, как-то не подумал о пустом интерфейсе почему-то. Вполне рабочая система, только правда придется для каждой реализации делать интерфейс свой, не очень вкусно звучит конечно. Но наверное более изящно эту проблему не решить.
По поводу парсить комменты также была мысля. По поводу если интерфейс реализуется 1 обьектом и ненужен согласен. Но, тут как раз проблема в том что интерфейс реализуется двоема обьектами и нельзя разобратся на основе его что инициализировать.
При IoC и так уже просходит dependency injection. Он жеж этим способом внедряет зависимости. Дело в том как понять какую зависимость внедрить на основе интерфейса если интерфейс реализует 2 класса но поразному.
То-есть в 1 строчке оно должно инжекнуть одну зависимость в класс а в другой другую того же интерфейса но которая уже в свою очередь реализует его по-другому.
Да, возможно отображение и лучше будет в плане быстроты набора кода и легкости с ним управления. Да вот только у нас в проекте слишком уж большой этот монстр доктрина будет. Проще(в плане быстродействия системы) использовать крайне легкий AR и велосипедом вроде конструктора запросов. В доктрине второй просадка скорости по сравнению с PLAIN SQL может быть в 3 раза иногда но и использовать PLAIN SQL тоже не особо хочется, вот и приходит крутится как-нибудь.
Но в проектах где быстродействие не так важно конечно доктрина хороший выбор.
Также имея в базе 30+ полей на каждой таблице, делать из set('filedName') setFieldName() думаю пустая трате методов. Т.е. таким образом класс будет иметь в основном методы для установку полей и через них уже и не будет видно самой функциональности класса + это получится тот же тотальный контроль входных и выходных данных что добавляет еще больше проблем чем я описывал выше.
Ведь в теории нету ничего плохого(наверно) что внешний мир может проставлять и получать любые данные в массиве $data который находится в AR классе и данные которого фильтруются при сохранении в базу НО при возврате данных с Join'ами ненужно делать дополнительных манипуляций с прописыванием полей которые появились.
Хотя, возможно есть некая ценность что возможно описанные в начале класса дополнительные поля который он возвращает позволит вспомнить что этот класс работает не только с полями текущей таблицы а еще что-то там JOIN'инть, поправьте если неправ.
Если добавлять в туже таблицу тогда никак не работает. Скорее всего через то, что 2 дефолтных роута и какой выбрать оно не знает.
Т.е. при создании ip rule add from x.x.x.x/y lookup Clear где Clear новая таблица и потом добавление нужных правил в эту таблицу, только тогда работает.
Спасибо большое. Это было именно то что нужно. Достаточно было создать новую таблицу и указать что все кто от B.B.B.C идут через новую таблицу. Вообщем решение в 3 строки.
а поточнее, предлагаете маршрутизацию на основе iptables строить? не уж-то нельзя прицепить 2 ip на интерфейс не прибегая к iptables? Ведь их ненужно никуда пробрасывать и т.д…
Да, к сожалению пока только selectel предлагает такую возможность защиты как фаервол. У других провайдеров такое не удалось найти. Поэтому хоть белый список и есть но воспользоватся им почти негде(не считая обычного фаервола на сервере)
2fortyseven
пообщавшись с поддержкой и изучив возможности API, подозреваю что там у них стоят все же не SRX 220 стоят, а что-то вроде SRX5600 или же хотя бы 3600. С этого исходит конечно что оборудование выдержит + вроде все же есть возможность добавлять не в CIDR нотации. Поэтому прошу прощение за преждевременные выводы.
К сожалению датацентр не говорит какое оборудование имеют, поэтому только и остается делать необоснованные выводы. Просто мне уже предлагалась похожая услуга, там в ДЦ стояли SRX240 и тоже говорили чтобы все будет держатся. Когда пришло время то, вы сами понимаете, пришлось искать дальше.
>>Можно указать большое количество адресов в CIDR нотации (1.1.1.1/32),
так добавлять адреса думаю только растрата ресурсов ;) хоть вы и правы, так можно.
ЗЫ. Скоро наступит время и я точно смогу сказать сколько они держут а сколько нет ;)
За мегабит что идет после фаервола.
Другое дело что у них помоему невозможно добавить 10к айпи не как CIDR а точные.И железки у них слабенькие, до 1Гбита держат. Разве что стоят по парам,… также неизвестно. Оборудование свое не называют, сколько их неизвестно, как стоит также молчат.
Никто не говорит что этот трафик постоянно идет, в случае его неуспеха он может прекратится и после 10 минут. Нужно просто выдержать пик.
Спасибо за предложение но ддос протекшн, променеджер и т.д. похожие сервис к сожалению это просто развод. Да я не спорю что они защищают от DDOSов определенных и вполне приемлемое решение за свои деньги. Но раз на то пошло то лучше взять напрямую туже аналитическую защиту у оверсана или базовую. Эффект будет тотже а вот по деньгам как минимум в 2 раза дешевле. Ведь они просто ее перепродают. К тому же когда берете напрямую общатся с поддержкой куда легче чем если через посредника ddos-protection или променеджер.
Но тут беда в другом, ни променеджер ни оверсан ни ддоспротекшн не держит ддос в 10Гбит. Скажу даже так, правильный ддос в 300Мбит-1Гбит они также не держат. Поэтому их защита не эффективна. К тому же ложных срабатывания при правильном ддосе иногда доходят до 80 процентов. А это недопустимо. Это я могу утверждать так как пробовал уже все эти защиты. Включая аналитическую защиту оверсана.
10-20к айпишек. Думаю в таких количества будет притормаживать разве что у них что-то вроде ipset.
+ я не вижу у них чтобы была возможность управлять этим фаерволом через апи, прийдеться ручками вбивать его а это не вариант.
+ непонятно где это оборудование стоит, уже в сети или на входе в ДЦ а также непонятно его производительность. Т.е. не факт что 10Гбит какого попало трафика его не положит просто прериваниями.
