首页 新闻 会员 周边 捐助

[请教]关于 .NET 应用的几个问题请教!!!

0
悬赏园豆:100 [已关闭问题] 关闭于 2008-05-15 16:44
1—— <BR>在.NET应用中,假如一个DLL想给多个应用程序共享,常规方案是注册到GAC,但这个方案很麻烦,需要注册,容易产生垃圾。 <BR>(比如在&nbsp;ASP.NET&nbsp;中,如果更新注册到GAC中的DLL非常不方便,特别是大型网站使用负载均衡时代码同步)。 <BR><BR>问题: <BR><BR>能否不注册到&nbsp;GAC&nbsp;也能让多个应用共享DLL?比如:某些项目可以把&nbsp;DLL&nbsp;放置到&nbsp;PROGRAM&nbsp;FILES&nbsp;文件夹的&nbsp;COMMON&nbsp;中来实现。 <BR><BR>2—— <BR>同问题1,在ASP.NET应用中,多个WEB站点使用了很多相同的DLL模块,能否让这些站点从相同的文件夹中获取?(不使用GAC方案)。 <BR><BR>3—— <BR>在&nbsp;.NET&nbsp;应用中,某个类具备一个&nbsp;VIRTUAL&nbsp;或&nbsp;ABSTRACT&nbsp;的方法或属性,其好处显而易见。 <BR><BR>问题: <BR>如何让派生的子类不能重载原本可以重载的方法或属性。
无之无的主页 无之无 | 大侠五级 | 园豆:5095
提问于:2008-03-27 10:40
< >
分享
所有回答(3)
0
不使用GAC好象比较困难. 放在一个地方理论上好象是可行的. Assembly.Load方法可以指定路径. 但是使用起来还是不方便吧.... 3. 这个应该是有确定性的吧,如果需要被覆写才作标记,如果不需要覆写那就不要标.
沙加 | 园豆:3680 (老鸟四级) | 2008-03-27 10:57
0
1,我更推荐每个程序都复制一份自己的私有程序集.这样部署起来更简单,单独升级也更容易.这也正是.Net的一个目标:XCopy部署. 如果一定要共享,我觉得还是放到GAC比较合适,因为GAC不仅仅是一个文件夹,它还有版本管理的功能,能在很大程度上避免dll hell. 2,可以,通过反射(Assembly.Load***),动态加载程序集. 不过这样一来就失去了"程序集一旦被修改,就自动重启AppDomain"的好处,可能还有很多其它方面需要注意和处理. 3,添加一个中间类,里面用new关键字重新定义一个与父类相同签名和访问公开性的非虚拟方法. 其实,这样的需求,倒不如不用继承,而是把父类拆分为几个接口,然后用Extension methods分别给不同的接口添加不同的方法.博客园前一段有人讨论过这种设计方法.
deerchao | 园豆:8367 (大侠五级) | 2008-03-27 14:04
0
对于问题一和二,其实都没必要,增加开发成本,同时这也是一种耦合的加强而已。 问题三 如果子类和父类不在一个dll中,比如 子类 class child 在child dll中,父类 class father 在 father.dll 那么只需要把father 里面的 virtual 方法定义个一个只有father.dll可见的类型。abstract方法则是必须实现的,否则编译都通不过的。 如果在同一个dll中,做这件事情是没有意义的,如果一个类不能继承,其他类都不能继承,那还virtual 什么?为了降低性能?
Birdshover | 园豆:352 (菜鸟二级) | 2008-03-28 01:24
清除回答草稿
   您需要登录以后才能回答,未注册用户请先注册