Что когда-нибудь происходило с Аспектно-ориентированным программированием? [закрытый]

Question

Что когда-нибудь происходило с Аспектно-ориентированным программированием? [закрытый]

Параметрированный запрос И проверка ввода - это путь. Существует множество сценариев, в которых может произойти SQL-инъекция, хотя используется mysql_real_escape_string().

Эти примеры уязвимы для SQL-инъекции:

$offset = isset($_GET['o']) ? $_GET['o'] : 0;
$offset = mysql_real_escape_string($offset);
RunQuery("SELECT userid, username FROM sql_injection_test LIMIT $offset, 10");

или

$order = isset($_GET['o']) ? $_GET['o'] : 'userid';
$order = mysql_real_escape_string($order);
RunQuery("SELECT userid, username FROM sql_injection_test ORDER BY `$order`");

В обоих случаях вы не можете использовать ' для защиты инкапсуляции.

Источник : Непредвиденная инъекция SQL (при эвакуации Недостаточно)

25

aop language-agnostic

задан Junior M 21 October 2010 в 13:17

5 ответов

Другие вопросы по тегам:

aop language-agnostic

Похожие вопросы:

score 5 · Answer 1

Это имеет тенденцию происходить с каждой «следующей большой вещью». Много шумихи, сопровождаемой медленным сокращением использования модного слова. Но, даже несмотря на то, что модные слова исчезают и в конечном итоге исчезают, все те хорошие идеи, которые стояли за ними, как правило, держатся, чтобы быть поглощенными мейнстримом.

[ Редактировать ] Хорошо, пример для тех, кто думает, что я что-то «избиваю» или утверждаю, что аспектно-ориентированное программирование исчезнет. Одно время следующей большой вещью было структурированное программирование. Из этого выросло объектно-ориентированное программирование, и теперь никто не говорит о выполнении «структурированного программирования». Но во многих отношениях мы все еще используем его лучшие идеи, потому что ООП принял их, улучшил их и добавил еще больше новых идей.

score 5 · Answer 2

AOP является на самом деле действительно блестящим, проблема с ним состоит в том, что никакой существующий язык не имеет действительно большой поддержка его. Верный C# имеет атрибуты (который только работает, когда Вы КОДИРУЕТЕ вещь), и Java имеет "инжекцию" (который создает путаницу из времени выполнения), но в целом нет никаких (основных) языков, которые имеют действительно большую поддержку его...

, Таким образом, этому отчасти нравится, закончил тем, что был "Шаблоном разработки" (с безумно различными реализациями на всех различных языках, хотя), который, в конце концов, не является всем, что плохо я предполагаю;)

score 5 · Answer 3

Это находится вокруг на некоторых проектах, мой собственный опыт в недавнем проекте, этим слишком легко злоупотребить: (!!! Что запустилось, хороший способ установить отладку, синхронизируя и некоторым расширяет управление транзакциями, это быстро было повреждено к самому странному, и самому твердому коду для понимания, и отладить это я видел в некоторое время.

только для расширения немного на стороне отладки/диагностики отслеживания стека, сгенерированные кодом AOP много раз, скрывают до неузнаваемости фактическое место, где исключение произошло.

score 2 · Answer 4

Я собираюсь предположить, что это не было достаточно большим. Это звучит очень привлекательным, но это действительно делает кодирование немного легче? Я желал испытать его и найти то, что приносит пользу ему, действительно содержит, но я не думаю, что делаю достаточно кодирования, где мне нужны отношения, которые это обеспечивает. Я не думаю, что это столь выгодно, как это звучит.

Также в этой точке, облегчая делать легче многоядерное программирование является большой вещью, и я не думаю, что аспектно-ориентированное программирование поможет с этим.

можно также найти много содержания на Риски Принятия .

score 36 · Answer 5

Возможно, в начале 2000-х было много шумихи, и произошло следующее: было много попыток создать аспектно-ориентированные фреймворки, и эти попытки объединились в два важных проекта в сфере Java. : AspectJ и Spring AOP. AspectJ - законченный, сложный, академический, несколько чрезмерно разработанный. Spring AOP покрывает 80% сценариев использования при 20% сложности.

Если вы посмотрите в Google Trends термины «AspectJ, Spring AOP» , а затем сравните с популярностью самой Java, вы увидите, что относительная популярность AspectJ в некоторой степени постоянна, но Spring AOP - повышение. Это означает, что люди используют АОП, но не хотят сложности AspectJ. Я считаю, что создатели AspectJ допустили множество тактических ошибок; AspectJ всегда был исследовательским проектом и не разрабатывался «для масс».

В сфере .NET мы наблюдали аналогичный интерес к АОП в начале 2000-х годов. В 2003 году, когда я начал исследования АОП, было полдюжины разработчиков АОП для .NET; все шли по пути AspectJ, и все находились на младенческой стадии. Ни один из этих проектов не сохранился. На основе этого анализа я создал PostSharp, который был разработан для охвата 80% сценариев использования с 20% сложности, но при этом был гораздо удобнее в использовании, чем Spring AOP. PostSharp сейчас считается ведущим разработчиком аспектов для .NET. PostSharp 2.0 основывается на 5-летней обратной связи и отраслевом опыте AspectJ и предлагает АОП "готовый к работе" (будущее покажет, заслуживают ли это утверждение). Помимо PostSharp, Spring Framework для. NET и Windsor Castle, двух ориентированных на DI фреймворков приложений, обеспечивающих аспекты «тоже» (аспекты рассматриваются как зависимости, внедренные в построенные объекты). Поскольку эти технологии используют переплетение во время выполнения, они имеют серьезные технические ограничения, поэтому практически их можно использовать только в сервисных объектах (для чего были разработаны эти каркасы приложений). Еще один начальный проект в .NET - LinFu, который может выполнять «также» аспекты.

Короче говоря, в последние годы ландшафт АОП претерпел некоторую консолидацию и, вероятно, вступит в фазу продуктивности: клиенты будут использовать его, потому что он действительно экономит деньги не потому что это круто. Даже если это очень круто:).