응용 프로그램의 비즈니스 규칙 중 중요한 부분이 특정 동작에 종속되어 있다고 가정하지만이 동작을 명시 적으로 코딩하면 코드가 복잡해집니다. PostSharp를 사용하여 측면에서 캡슐화하거나 그 문제에 대한 다른 aspect 프레임 워크)? 그것은 "안전하고" "현명한"옵션입니까, 아니면 코드를 어떻게 복잡하게 만들 것인지에 관계없이 항상 명시 적으로 코드를 작성하는 것이 더 나은가요? 그러한 솔루션의 유지 보수 가능성은 어떻습니까?포스트 샤프 및 중요한 코드 파트
비즈니스 규칙 또는 비즈니스 논리를 여러 측면에서 권장하지 않습니다. 그것은 AOP의 목적에 어긋납니다. 비즈니스 규칙/논리는 교차 절단 문제가 아닙니다. 비즈니스 로직의 일부를 혼란으로 생각한다면 일반적인 OOP 프랙티스를 사용하여 추상화하거나 자체 메소드로 추출해야합니다.
당신은 물론 그것을 aspect로 옮길 수 있지만, 목표는 무엇입니까? 혼란을 줄이려면? 그것은 나에게 용납되지 않는다. 비즈니스 논리와 관련이없는 혼란을 없애기 위해 측면을 사용하여 비즈니스 논리가 명확합니다. 비즈니스 논리가 복잡하다면 리팩터링해야합니다.
PostSharp와 다른 AOP 프레임 워크 : "중요 코드"를 한면에 넣으면 결국 PostSharp가 최상의 성능을 얻을 수있는 최상의 프레임 워크가됩니다. IoC와 같은 런타임 프레임 워크에는 동적 차단이 정적으로 컴파일 된 코드와 함께 수행되지 않는다는 내용이 포함되어 있습니다. 또한 PostSharp에는 작성한 코드를 기반으로 수행되는 최적화가 너무 많아서 다른 프레임 워크가 일치 할 수 없습니다.