グレッグ・ヤングがKISSに人々に警告するこの講演を見ました：Keep It Simple Stupid。
彼が提案したことの1つは、アスペクト指向プログラミングを行うために、フレームワークを必要としないということです。
彼は強力な制約を作成することから始めます。すべてのメソッドは1つだけのパラメーターを取ります（ただし、彼は部分適用を使用してこのパラメーターを少し緩めます）。
彼が与える例は、インターフェースを定義することです：
public interface IConsumes<T>
{
void Consume(T message);
}
コマンドを発行したい場合：
public class Command
{
public string SomeInformation;
public int ID;
public override string ToString()
{
return ID + " : " + SomeInformation + Environment.NewLine;
}
}
コマンドは次のように実装されます。
public class CommandService : IConsumes<Command>
{
private IConsumes<Command> _next;
public CommandService(IConsumes<Command> cmd = null)
{
_next = cmd;
}
public void Consume(Command message)
{
Console.WriteLine("Command complete!");
if (_next != null)
_next.Consume(message);
}
}
コンソールへのロギングを行うには、次を実装するだけです：
public class Logger<T> : IConsumes<T>
{
private readonly IConsumes<T> _next;
public Logger(IConsumes<T> next)
{
_next = next;
}
public void Consume(T message)
{
Log(message);
if (_next != null)
_next.Consume(message);
}
private void Log(T message)
{
Console.WriteLine(message);
}
}
次に、プリコマンドロギング、コマンドサービス、およびポストコマンドロギングは次のようになります。
var log1 = new Logger<Command>(null);
var svr = new CommandService(log);
var startOfChain = new Logger<Command>(svr);
コマンドは次によって実行されます：
var cmd = new Command();
startOfChain.Consume(cmd);
たとえば、これをPostSharpで行うには、CommandService次のように注釈を付けます。
public class CommandService : IConsumes<Command>
{
[Trace]
public void Consume(Command message)
{
Console.WriteLine("Command complete!");
}
}
そして、次のような属性クラスでロギングを実装する必要があります。
[Serializable]
public class TraceAttribute : OnMethodBoundaryAspect
{
public override void OnEntry( MethodExecutionArgs args )
{
Console.WriteLine(args.Method.Name + " : Entered!" );
}
public override void OnSuccess( MethodExecutionArgs args )
{
Console.WriteLine(args.Method.Name + " : Exited!" );
}
public override void OnException( MethodExecutionArgs args )
{
Console.WriteLine(args.Method.Name + " : EX : " + args.Exception.Message );
}
}
Gregが使用する引数は、属性から属性の実装への接続が「あまりにも多くの魔法」であり、ジュニア開発者に何が起こっているかを説明できるということです。最初の例はすべて「単なるコード」であり、簡単に説明できます。
だから、かなり長めのビルドアップの後、質問は次のとおりです。Gregの非フレームワークアプローチからPostSharp for AOPのようなものを使用するように切り替えるのはいつですか。
3
+1：間違いなく良い質問です。「...それなしで解決策をすでに理解しているとき」と単純に言うかもしれません。
—
スティーブンエバーズ
たぶん私はそのスタイルに慣れていないだけかもしれませんが、このようなアプリケーション全体を書くという考えは、まったく正気でないように思います。むしろメソッドインターセプターを使用します。
—
アーロンノート
@Aaronaught：はい、それが私がここに投稿したかった理由の一部です。Gregの説明では、システム構成は、すべての異なる
—
ピーターK.
IConsumes部分を通常のコードで接続しているだけです。外部XMLやFluentインターフェイスを使用する必要はありません---もう1つ覚えておく必要があります。この方法論も「学ぶべき別のこと」であると主張することができます。
私はまだその動機を理解できません。AOPなどの概念の本質は、構成によって懸念を宣言的に表現できることです。私にとって、これは単なる四角い車輪の再発明です。あなたやあなたの質問に対する批判ではありませんが、唯一の賢明な答えは「他のすべてのオプションが失敗しない限り、グレッグのアプローチを使用することは決してないだろう」と思います。
—
アーロンノート
それがまったく気になるわけではありませんが、これはもう少しスタックオーバーフローの質問ではないでしょうか？
—
宮坂