标签: aop

我在这里提到了AspectJ参考,它指出'cflow'是

cflow(Pointcut) - 由Pointcut选取的每个连接点P的控制流中的每个连接点,包括P本身

这对我来说并不完全清楚,我想知道是否有人可以详细说明cflow的含义吗？为什么要用它？

非常感谢.

我知道日志记录是AOP的主要用例.此外,日志记录包装器也可以作为您希望使用DI的示例,以便类不与特定的日志记录实现相结合.但是,有些人认为日志包装器是一种反模式.首先,这样的视图是因为在大多数情况下,包装器往往是简单的并且删除了特定于日志框架的许多特征.如果您实现这些特定功能,为什么不直接使用框架.

我知道Common.Logging外观试图为您提取log4Net,EntLib,NLog的大量功能.但是,即使在这里,我们仍然依赖于Common.Logging.不是关于接口等的代码/单元测试方式,但如果项目死亡(自上次发布以来已超过一年)或者您希望后者切换到不支持的记录器,则可能导致问题.

也就是说,如果通过AOP实现日志记录,是否有必要使用DI作为日志记录依赖项(即为什么不直接引用说NLog)？是的,AOP部分代码将紧密耦合,但是想要进行单元测试的类的逻辑缺乏记录依赖性(至少在编织发生之前).在这一点上,我有点迷失(我还没有尝试过AOP).编织后,没有使用DI作为AOP代码会导致单元测试被测方法的问题吗？或者可以在不编织AOP代码的情况下测试一个单元吗？

除非日志记录是软件用户的要求,否则我不确定测试日志是否与模拟有关是多么有用.我认为被测方法的业务逻辑是大多数人对测试感兴趣的东西.最后,如果想要使用TDD/BDD,是否必须在AOP代码中使用DI来记录日志依赖？或者只是不测试驱动 AOP方面的东西？

正如您所看到的,我正在尝试了解最实用的方法是开发一个应用程序,该应用程序将AOP用于横切关注点,DI用于设计/测试.由于AOP相对较新,而日志记录是最常见的例子,推荐的方法是什么？

我主要是一名Java开发人员.我遇到了很多喜欢AOP的Java开发者.我也看到越来越多的AOP"设计模式"最近出现,似乎被广泛采用.即便如此,由于几个原因,我仍然不相信OO代码中的AOP通常是个好主意.

1. 它以不透明的复杂性形式为代码添加了"魔力",这可能非常难以调试,并且可能使调试它所影响的面向对象的代码变得非常困难.

2. 在我看来,大多数情况下是不必要的,而且(更糟糕的是)经常习惯于避免设计好,或者补偿以前糟糕的设计.

这是我在过去几年中经常看到的一个例子,作为我的问题的背景.

在AOP之前(来自Hibernate文档)

public void saveMyEntityToTheDatabase(MyEntity entity) {
    EntityTransaction tx = null;
    try {
        tx = entityManager.getTransaction();
        tx.begin();
        entityManager.persist(entity);
        tx.commit();
    } catch (RuntimeException e) {
        if(tx != null && tx.isActive()) {
            tx.rollback();
        }
        throw e;
    }
}

AOP之后

@Transactional
public void saveMyEntityToTheDatabase(MyEntity entity) {
    entityManager.persist(entity);
}

对许多人而言,AOP似乎是一个明显的胜利.对我来说,原始问题是API抽象级别不一致的症状.也就是说,它EntityManager比使用它的消息的业务级API低很多.这个问题可以通过更合适的抽象级别和更好的(OO)设计来解决.

OO解决方案

public void saveMyEntityToTheDatabase(MyEntity entity) {
    database.performInTransaction(new Save(entity));
}

此解决方案假定database对象包含与负责管理@Transactional方法的方面相同类型的事务逻辑.这解决了我上面关注的问题,因为它更明显地表明存在管理与之交互的东西EntityManager,而不是引入另一种编程范例.

最后,我的问题是:AOP可以做什么OOP不能？我有点确信它在跟踪日志记录中的用处,也许是默认toString()实现或类似的东西,但我很想知道是否有人发现它比OO明显优于特定类型的问题.

我可以对大多数Spring类进行单元测试,而无需执行Spring"东西".

我也可以在不使用Spring的情况下对@Before建议方法进行单元测试:

示例代码:

@Before("execution(* run(..)) && " + "" +
          "target(target) && " +
        "args(name)")
public void logName(Object target, String name) {
    logger.info("{} - run: {}", target, name);
}

示例测试:

@Test
public void testLogName() {
    aspect.setLogger(mockLogger);
    aspect.logName(this,"Barry");
    assertTrue(mockLogger.hasLogged("TestAspect - run: Barry"));
}

但是@Around建议处理ProceedingJoinPoint对象:

@Around("com.xyz.myapp.SystemArchitecture.businessService()")
public Object doBasicProfiling(ProceedingJoinPoint pjp) throws Throwable {
   // start stopwatch
   Object retVal = pjp.proceed();
   // stop stopwatch
   return retVal;
 }

我不知道如何实例化ProceedingJoinPoint对象.如何在不启动整个Spring应用程序上下文的情况下测试此类？

我在春天读了目前和用于使用AOP的测井方法调用的开始和结束的一个例子.

我还读到使用AOP会影响性能.

对于这种类型的日志记录,使用Spring AOP是个好主意吗？我的理解是Spring使用Dynamic AOP会更好地将静态AOP(如AspectJ)用于这种类型的AOP.

Curently在我工作的公司的编码策略需要记录的一个可笑的量,我想,以减少日志代码的ammount的我必须写,并提高我的代码的可读性.

我吠叫错了树吗？

问题

我正在通过ExecutorService运行一些外部方法的多次调用.我希望能够中断这些方法,但遗憾的是它们不会自行检查中断标志.有什么办法可以强制从这些方法中引发异常吗？

我知道从任意位置抛出异常是有潜在危险的,在我的具体情况下,我愿意抓住这个机会并准备应对后果.

细节

"外部方法"我的意思是来自外部库的一些方法,我不能修改它的代码(我可以,但是每当新版本发布时,这将使它成为维护的噩梦).

外部方法计算成本高,不受IO限制,因此它们不响应常规中断,我无法强行关闭通道或套接字等.正如我之前提到的,他们也没有检查中断标志.

代码在概念上类似于:

// my code
public void myMethod() {
    Object o = externalMethod(x);
}

// External code
public class ExternalLibrary {
    public Object externalMethod(Object) {
        innerMethod1();
        innerMethod1();
        innerMethod1();
    }

    private void innerMethod1() {
        innerMethod2();
        // computationally intensive operations
    }

    private void innerMethod2() {
        // computationally intensive operations
    }
}

我试过的

Thread.stop()理论上我会做我想要的,但它不仅被弃用,而且它也只适用于实际线程,而我正在使用执行器任务(也可能与未来任务共享线程,例如在线程池中工作时) .然而,如果找不到更好的解决方案,我将转换我的代码以使用老式的Threads并使用此方法.

我尝试过的另一个选择是myMethod()使用特殊的"Interruptable"注释标记和类似的方法,然后使用AspectJ(我无疑是新手)来捕获所有方法调用 - 类似于:

@Before("call(* *.*(..)) && withincode(@Interruptable * *.*(..))")
public void checkInterrupt(JoinPoint thisJoinPoint) {
    if (Thread.interrupted()) …

我想在这里要求3个信息:

1. 在Microsoft的 C#(.Net)中,没有面向方面编程(AOP)的集成解决方案是正确的吗？是否有任何此类解决方案正在开发或计划中？

2. 哪些解决方案允许在C#(.Net)中使用面向方面编程(AOP)？它们的优点/缺点是什么？我没有找到任何包含所有可用选项的综合列表和一些信息供我决定使用哪一个.最接近的是这个列表.

3. 什么是(在您看来)考虑以下标准的C#(.Net)的最佳AOP解决方案:

   1. 它可以像AspectJ一样工作,并且具有类似的语法
   2. 使用简单:不需要XML配置 - 只需编写一些常规类,一些方面类并编译以将它们编织在一起,然后运行.
   3. 应该包括AspectJ的所有功能.支持泛型.
   4. 解决方案应该稳定,广泛使用和维护.
   5. 应提供编织二进制文件(可以使用)或C#源代码.
   6. 用于可视化(甚至更好 - 插件到VS)的GUI工具是一个优势.

我认为,如果某些内容满足3中的大多数标准,那么它就是常用解决方案的候选者.如果某些现有解决方案符合我的需求,我无处可寻.

我不是在谈论模仿Scala中的AOP功能(即使用Traits而不是Aspects),我想知道是否有可能在Scala中做真正的AOP(即建议,方面,关节点,编织等......)

我目前正在尝试使用Spring框架进入Java EE开发.由于我是Spring的新手,很难想象一个好的运行项目应该如何开始.

你有什么最好的做法,tipps或主要的DO NOTs 为首发？你是如何从Spring开始的 - 大项目或类似教程的小应用程序？您使用了哪种技术:AOP,复杂的Hibernate ......

您使用哪个Javascript AOP库,它的主要功能是什么？