Posted on 2004-04-18 20:09
hbifts 阅读(5612)
评论(34) 编辑 收藏 网摘 所属分类:
AOP
Good~
我们
博客园的开源项目
Aop.NET 已成功进驻
Sourceforge.net.
项目地址是:
http://sourceforge.net/projects/aopnet/项目成员为:
hBifTs,
dudu,
steeven项目介绍:
AOP.NET (NAop) 是.NET下面的一个 Aspect Oriented Programming (AOP) (面向方面编程)框架 (GPL).
我们现在实现的方法是基于.NET Reflection.Emit 实现的DynamicProxy..
现在Release的版本是0.1,还是一个比较简单的框架(可能也算不上框架吧
).
功能再进一步进行完善..
此外,博客园还有一个开源项目
steeven在http://www.gotdotnet.com申请了的关于AOP的项目: DotNetAOP
项目地址: http://www.gotdotnet.com/Community/Workspaces/Workspace.aspx?id=1b78f7c1-895f-49a7-8fa6-1565db16d41b
这个的实现方法和上面的Aop.NET不同.这个是通过.NET Remoting实现的.
一些关于AOP的链接:
http://www.cnblogs.com/hbifts/category/1695.aspx
http://www.cnblogs.com/dudu/category/1189.aspx
http://aosd.net
有兴趣的同学/程序员可以自行下载试用.使用方法可以参考源代码中的TestCase..
有任何意见/建议请与我联系...我们会尽全力做好这两个开源项目.
for cnblogs.for our dream...
Feedback
能具体解释一下有关AOP、NAOP以及目的、意义等吗？
@ccBoy
呵呵，到时候会向你请教的呢
@skyover
AOP 面向方面编程
Have no idea about it. Sound like a cool project. I would like to know more.
呵呵,,主要是要用英文写注释.比较的麻烦..
先不写,,过几天写文档出来吧~
@hBifTs:
很高兴看到你们建立的这个开源项目！你们一定可以成功！如果需要帮助可以随时和我联系，虽然偶最近工作十分繁忙且上网不是很方便，不过还是希望能够为这件事情做些有意义的贡献。：）
呵呵,谢谢JGTM'2004..
到时候有一些问题肯定会请教您的:P
我觉得是不是给一个什么是AOP的介绍或者连接，不然像我这样的菜鸟要看得云里雾里的。
此外，如果是Emit的话，我还是比较有兴趣关注的。
这样的项目和rapier loom.net（http://www.dcl.hpi.uni-potsdam.de/cms/research/loom/）有多大区别啊？人家已经做得比较成熟了，在做一样的没多大意义吧。另外，这种基于类库的动态weave效率很低（以目前已知的技术还没有有效的算法可以比较快速的完成weave），而且集成也不是透明的（必须通过特定的函数来创建对象），多少有些违背AO的初衷。个人不看好这种动态weaver，如果作动态weaver，我觉得做load-time weaving意义大一些，但速度仍然是一个问题。
不过出现这种项目还是很好的事，说明国内的.net社区已经走在世界前沿了。
最好能够把log，excetion,transaction,secrity这四个东西实现了，做为demo
并且这样也可用发现一些另外的架构需求或问题。
很不错的AOP.net
我觉得emit是方向～～～
ContextBoundObject的做法唯一优势就是能用new，这个是没有办法的，CLR给的特权。
提几个发展的想法：
1、结合IoC/Dependency Injection，把对象的创建过程变得更加好看
2、把DBC做好，参考参考extensible C#
3、编写add-in或者工具，同步Attribute和xml描述，这样选择更加灵活了
我觉得可以以这个AOP.net为核心，作一个Spring的.net版本，虽然它们也在作。
非常感谢您的指导。。
：P
关于DBC，这个已进入了我们的Todo list：P
应该不出多长时间就可以拿出一个初步的版本出来的～
指导哪里谈得上，AOP.net给我帮助很大的说，非常希望看到它能做得更好。
我们交换一下链接吧，我的：taowen.blogdriver.com
我的MSN：nctaowen@hotmail.com
首先应该说很高兴看到国人在sourceforge上的项目。对于naop，也有跟taowen类似的感受，就是对象的创建过程不透明有一些违背aop思想。还有要求类必须实现接口，显然这增加了设计的限制，抛开NAop，毫无疑问很多情况下并不需要抽象出接口，当然这是因为.Net机制的限制。
另外关于DbC这部分实现得过于简单，也许是我理解不够，感觉只针对precondition考虑，而且是固定的判定（NotNull）。我想要支持DbC,至少要支持precondition/postcondition，不变式可以考虑，应当支持使用表达式表示条件。而且基于效率的原因和DbC的目的（很多时候仅用于开发阶段差错），应当允许取消DbC的检测，这一点naop的机制是无法实现。但无论如何，使用Aop方式至少提供了一个选择。
无论如何，你们的努力值得尊敬，希望naop发展壮大。
我在sourceforge上提交项目被拒绝，说是缺少描述或许可不全，我再重新提交，我想问如果通过后，代码和CVS是如何提交和配置的？
airhand@163.com
非常感谢！
偶觉得AOP“勾”住Interface就好，没有必要搞什么支持virtual的方法。
你做的是一个框架，别人要用你的，必定需要重构他的代码，不管是用接口，还是virtual方法。
你们想不用interface的想法是好的，但是事实这样做不到，别人把方法改成vitual与Extract Interface有什么区别？大家都要改原有代码，而抽取接口，则是标准重构方式，更易被人接受。
另外，给兄弟们一个建议，要搞好国人的AOP.Net，不应当把目光只注意在.Net方面其它人的AOP框架，而应当盯在Java领域。
Java中已经有不少成熟的AOP框架，比如Spring中的AOP，JBOSS中的AOP，Hibernate中的AOP，这些都是已经做得不错的东东。学他们进步更快。
偶觉得AOP“勾”住Interface就好，没有必要搞什么支持virtual的方法。
你做的是一个框架，别人要用你的，必定需要重构他的代码，不管是用接口，还是virtual方法。
你们想不用interface的想法是好的，但是事实这样做不到，别人把方法改成vitual与Extract Interface有什么区别？大家都要改原有代码，而抽取接口，则是标准重构方式，更易被人接受。
如果需要不修改原有代码，最好还是使用AspectJ这样的静态代理。
另外，给兄弟们一个建议，要搞好国人的AOP.Net，不应当把目光只注意在.Net方面其它人的AOP框架，而应当盯在Java领域。
Java中已经有不少成熟的AOP框架，比如Spring中的AOP，JBOSS中的AOP，Hibernate中的AOP，这些都是已经做得不错的东东。学他们进步更快。
问个相关的问题，.net中有什么暴力修改字节码的工具没？
今天才看到这文章，看到NAop。
我刚做了一个NAOP，汗，居然不知道NAop早已存在。