Здравствуйте, Sinix, Вы писали:
S>А-а-а. Можно спросить — сценарий с VPN / proxy не рассматривался? или было решено что квалификации саппорта не хватит? Это ж блин джамшутинг — городить самописный шлюз из-за отсутствия админа...
С этим заказчиком вообще история тёмная и всех деталей я не знаю — мне эта система на саппорт досталась. К моему удивлению, работает очень стабильно S> S>Понимаете, когда я обсуждаю архитектурные вопросы, я сразу смотрю: а что будет если этот участок станет боттлнеком? S>И что мне за это сделают. Отрицательная обратная связь — оччень дисциплинирует. Идеи типа "а если побольше пороху — то оно и в космос выйдет" отметаются моментально. Заодно и время экономится.
Проблема в том, что в данном случае вы не можете знать, станет ли это действительно боттлнеком, ибо вам не известно ни назначение приложения, ни его нагрузочные параметры. Более того, по моим прикидкам и экспериментам, при типичном для "базаморд" паттерне работы — загрузка словарей при старте, потом сравнительно редкие запросы туда-сюда — эта кухня без проблем вытянет десяток-другой одновременных подключений...
S>Неа Это очень хреновая философия — сделаю абы как, потом решим. А потома не будет. Будет вечный дедлайн из-за того что у вас не хватает времени разгрестись с предыдущими проблемами (которые основная причина дедлайна). Вот эта вечная дурная вера в "потом": потом будет время — сделаю, потом будут деньги — верну кредит, потом займусь здоровьем... — она больше всего проблем и создаёт.
Покажите мне, где я сказал, что нужно что-то делать? Я всего лишь говорю о том, что в процессе принятия решения нужно рассмотреть как можно больше альтернатив, если надо осуществив прототипирование, и только потом реализовывать выбранное решение. Не нужно приписывать мне то, чего я не говорил S>
S>Уххх... вот как оно со стороны выглядит... Я просто пытаюсь сэкономить время — на основе того что предложили выдаю решение с наибольшим запасом прочности, когда тыкнут в узкие места — подправляю. Но ни один из своих советов "решением на блюдечке" не назову — как всегда, дьявол в мелочах, которые дольше расписывать чем додуматься самому. В конце-концов, каждый ССЗБ
Вам ещё не говорили про овердизайн и premature optimization? Чаще всего не нужно решение с наибольшим запасом прочности — но нужно решение, "прочность" которого достаточна для исполнения ТЗ + имеет некоторый запас (зависит от ситуации). А ваш подход часто заканчивается рождением монстра типа MEF, который имеет гигантский запас прочности, но для подавляющего числа реальных сценариев оказывает жёстким оверкиллом... Так кто там про овердизайн-то говорил?
Здравствуйте, koandrew!
K>С этим заказчиком вообще история тёмная и всех деталей я не знаю — мне эта система на саппорт досталась. К моему удивлению, работает очень стабильно
Ну так, по запросу в час... мне ваши масштабы — ухх я бы развернулся
K>Проблема в том, что в данном случае вы не можете знать, станет ли это действительно боттлнеком, ибо вам не известно ни назначение приложения, ни его нагрузочные параметры.
Вы слегка не уловили идею. Я не рассматриваю сценарии "оно может сработать". Я сразу смотрю, что будет "когда оно поломается" и прикидываю сложность подержки. С этой точки зрения VPN выигрывает моментально, т.к. не оказывает никакого футпринта на всё остальное приложение. Решение проблемы не должно создавать новых.
K>Покажите мне, где я сказал, что нужно что-то делать? Я всего лишь говорю о том, что в процессе принятия решения нужно рассмотреть как можно больше альтернатив, если надо осуществив прототипирование, и только потом реализовывать выбранное решение. Не нужно приписывать мне то, чего я не говорил
Ну, вас лично я в виду не имел. Отреагировал на фразу "Но опять-таки есть ситуации, когда часть проблем можно решить, а на другую часть просто забить".
А вашу "альтернативу" надо отбрасывать как можно раньше, чтобы не засорять мозг бесперспективными решениями. Вы почитайте как и когда используется мозговой штурм. Эта техника рулит, когда фантазия бздык, а хоть какое решение надо уже вчера. Да и то, только помогает перейти собственно к продуктивному обсуждению.
K>Вам ещё не говорили про овердизайн и premature optimization? Чаще всего не нужно решение с наибольшим запасом прочности — но нужно решение, "прочность" которого достаточна для исполнения ТЗ + имеет некоторый запас (зависит от ситуации).
Неа, потому что запас прочности != overdesign. Наоборот, запас прочности невозможен без минимального влияния на остальные части приложения. И забудьте про ТЗ как единственный источник объективной информации для архитектуры — требования имеют пошлое свойство меняться, а дизайн (в идеале) не должен тасоваться туда/сюда от каждой финтифлюшнки.
K>А ваш подход часто заканчивается рождением монстра типа MEF, который имеет гигантский запас прочности, но для подавляющего числа реальных сценариев оказывает жёстким оверкиллом...
Это MEF-то овердизайненный? Вы System.Addins щупали? Или EntLib. Или NLog? MEF концептуально очень красивая штука. И для средней сложности систем почти таки подойдёт. По мне, показательно что VS Team и Blend team добровольно MEF используют. Что кстати и привело к включению MEF в фреймворк.
Скорее ваше решение с подменой DAL, поднятием сервиса и собственным протоколом выглядит овердизайном.
Так кто там про овердизайн-то говорил?
Re[12]: WinForm приложение+MS SQL, как организовать авториза
Здравствуйте, Sinix, Вы писали:
S>Вы слегка не уловили идею. Я не рассматриваю сценарии "оно может сработать". Я сразу смотрю, что будет "когда оно поломается" и прикидываю сложность подержки. С этой точки зрения VPN выигрывает моментально, т.к. не оказывает никакого футпринта на всё остальное приложение. Решение проблемы не должно создавать новых.
Насколько я понял, уломать админов пустить нас в VPN не удалось... Ваши действия?
S>Ну, вас лично я в виду не имел. Отреагировал на фразу "Но опять-таки есть ситуации, когда часть проблем можно решить, а на другую часть просто забить".
S>А вашу "альтернативу" надо отбрасывать как можно раньше, чтобы не засорять мозг бесперспективными решениями. Вы почитайте как и когда используется мозговой штурм. Эта техника рулит, когда фантазия бздык, а хоть какое решение надо уже вчера. Да и то, только помогает перейти собственно к продуктивному обсуждению.
Ну значит мы используем другой подход к штурму — когда сначала кидаются все идеи, которые приходят в голову, а потом уже каждая индивидуально обсуждается и принимается решение...
S> S>Неа, потому что запас прочности != overdesign. Наоборот, запас прочности невозможен без минимального влияния на остальные части приложения. И забудьте про ТЗ как единственный источник объективной информации для архитектуры — требования имеют пошлое свойство меняться, а дизайн (в идеале) не должен тасоваться туда/сюда от каждой финтифлюшнки.
Тут уже были дебаты на эту тему — не хочу повторений. Моё мнение — архитектура как "вещь в себе" — достаточно бесполезная штука...
S>Это MEF-то овердизайненный? Вы System.Addins щупали? Или EntLib. Или NLog? MEF концептуально очень красивая штука. И для средней сложности систем почти таки подойдёт. По мне, показательно что VS Team и Blend team добровольно MEF используют. Что кстати и привело к включению MEF в фреймворк.
Тока вот почему-то я не видел проектов, построенных на ней, за исключением названных вами... Зато вот велосипедов я повидал предостаточно. Да и на базе той же Unity рабочий движок пишется за несколько часов... S> S>Скорее ваше решение с подменой DAL, поднятием сервиса и собственным протоколом выглядит овердизайном. S>Так кто там про овердизайн-то говорил?
Подмена DAL — это официальный и документированный метод выбора провайдера в ADO.NET. В пднятии сервиса на WCF тоже не вижу проблемы, и протокол изобретать совсем не нужно — достаточно заюзать WCF (если надо поверх SSL)...
В общем предлагаю пока свернуть эту дискуссию, ибо она явно уходит в оффтоп, и подождать, чё топикстартер скажет...
Здравствуйте, koandrew, Вы писали:
K>Насколько я понял, уломать админов пустить нас в VPN не удалось... Ваши действия?
Очень просто — объясняю заказчику причины по которым его требования нереализуемы. В итоге: либо меня избавляют от решения их проблем, либо я нахожу общий язык с товарищем (какая ему собачья разница — хрен знает какой сервис выставить или vpn открыть), либо админ получает втык и таки начинает работать
K>Ну значит мы используем другой подход к штурму — когда сначала кидаются все идеи, которые приходят в голову, а потом уже каждая индивидуально обсуждается и принимается решение...
Дык это ж только затравка перед обсуждением. Штурм длится минут пять максимум. И желательно за кофечаем. Иначе из мегаштуки мозгоштурм превращается в унылое "а вот у меня идея" по десятому кругу. Наверное мы его по разному готовим.
K> K>В общем предлагаю пока свернуть эту дискуссию, ибо она явно уходит в оффтоп, и подождать, чё топикстартер скажет...
Ага, что-то мы разошлись... Спасибо за дискуссию!
Re[6]: WinForm приложение+MS SQL, как организовать авторизац
Здравствуйте, Sinix, Вы писали:
S>Эххх. Чрезмерно-детализованная RBS бесполезна. Ролей должно быть как можно меньше. В идеале — по 1 на модуль системы. Тонкий тюнинг должен делаться как row-level-security (RLS) с конкретными принципалами и конкретными сущностями (обязательно с наследованием).
почитал линк, который вы дали, что-то сильно яснее не стало.
Почему мой вариант недоделанный RLS или передизайненный role-based непонятно.
Может есть хорошие статьи в интернете ?
Под RLS я так понял понимаются права доступа к конкретным сущностям, например кто-то может иметь право на чтение сущности "Отдел", но менять ее не может. Это так ?
Нам-же все-таки требуется разграничение по доступным функциям, т.е. определенный человек не имеет права выполнять определенную операцию. Это я так понимаю role-based, но вот почему она недодизайненная ?
И почему много ролей это вдруг плохо ?
S>Да-да. Но это кривой дизайн, т.к. вы совмещаете в 1 механизме 2 разных: S>- проверку доступа к API (делается силами субд через роли) S>- зачаточный RLS aka разрешения на конкретные действия над конкретными сущностями (тут нужен в принципе другой механизм).
какой механизм ?
Re[3]: WinForm приложение+MS SQL, как организовать авторизац
Здравствуйте, Stalker., Вы писали:
S>А вот что делать в следующей ситуации:
S>У нас система безопасности сделана таким образом: все пользователи имеют свой аккаунт в базе, в программе хранится только строка подключения без логина и пароля — они вводятся пользователем и присоединяются к строке перед подключением к БД.
S>Пользователи обьеденены в роли, есть ХП, которая возвращает название ролей, к которым принадлежит текущий пользователь и на основании этого дисайблит определенные контролы/функции
S>Все хорошо до тех пор, когда не захочется динамически настраивать доступ к функциям. Скажем, администратор захочет добавлять новые роли или например запретить доступ к какой-нибудь функции для определенной роли. S>Как это делать ? Ничего в голову не приходит ...
посмотрите как работает MS Repository, тот что в составе Oslo.
Это очень хреновая философия — сделаю абы как, потом решим. А потома не будет. Будет вечный дедлайн из-за того что у вас не хватает времени разгрестись с предыдущими проблемами (которые основная причина дедлайна). Вот эта вечная дурная вера в "потом": потом будет время — сделаю, потом будут деньги — верну кредит, потом займусь здоровьем... — она больше всего проблем и создаёт.
