Как ввести AOP в продуктивную разработку программного обеспечения?
Я знаю, что этот вопрос задали прежде, но это было полтора года назад, хотя я думал, что это могло бы быть время для переопроса. Я также распознал, что это могло бы рассматриваться как субъективное, но я предполагаю, что существуют объективные причины AOP.
Я интересовался бы тем, кто использует AOP в разработке программного обеспечения и также почему или почему не использование его.
Я рассматриваю AOP как очень сильную парадигму, которая может сделать много задач разработки легче. Но когда дело доходит до использования AOP в проектах реального мира я сделал опыт, что многие лица, принимающие решения, едва открыты для него. Как Вам удавалось ввести AOP в Ваши проекты?
Ранее заданный вопрос с августа 2008: Вы используете AOP (Аспектно-ориентированное программирование) в производственном программном обеспечении?
3 ответа
Наши менеджеры слушают свою команду архитектуры.
Мы говорим им, что AOP является единственным решением для реализации функций кросс-концерна:
- в разумной стоимости в первую очередь
- без вощения с функциональным кодом, написанным командой разработки
- , не забывающих (По сравнению с вручную добавлять попробовать тысячи методов), теперь и в будущем
- без необходимости тренироваться или контролировать то, что делают разработчики (некоторые великие, другие являются настоящим беспорядком)
- Хорошая ремонтопригодность
True, наш проект - 20 разработчиков и длилось несколько лет, поэтому существует огромная масса кода. Это единственное решение.
Я считаю, что ключ - использовать его только для сквозных проблем. Если вы можете кодировать его, используя обычный код, сделайте это. Но если это слишком большой, то AOP привлекателен и оправдан. Неспособность ограничить AOP привело бы к сотен небольших кодов AOP, это было бы очень трудно понять.
И да, наше программное обеспечение - производственное программное обеспечение. Сотни клиник зависят от этого!
Мы не используем AOP 100% как таковой, но да, мы используем его всякий раз, когда считаем это целесообразным (в основном Весенний AOP; это так мило интегрировано с Весенним фреймворком)
Как вам удалось внедрить AOP в ваши проекты?
Ну, отделите перекрестные проблемы, например, вызовы методов трассировки. В весеннем AOP вы можете определить аспект (поведение во время выполнения), который будет применен к "подключенному" разделу кода. С помощью "hooked" я имею в виду, что вы должны быть в состоянии сгруппировать все методы, где вам нужно такое поведение, под одним общим зонтиком. Во время выполнения, этот код получит новое поведение, определенное вашим аспектом.
Spring AOP AS AS Pereit Beyit легко ввести, если вы уже используете Spram Framework в вашем проекте.
Я впервые добавил Aspectj для наших инструментов проекта, который используется только внутри и никогда не выпущен к клиентам. Это помогло как команду разработки, так и руководством, чтобы получить доверие к инструменту и иметь четкое представление о том, что он может сделать для них.