朋友landws做的一个ORM Component

    Grove Develop Component Kit 包括 Grove Develop Component 和 Grove Tool Kit两部分;
    Grove Develop Component是一套基于Microsoft .NET Framework的可重用开发组件,支持多种不同数据库项目,提供标准的二层,三层及多层等开发框架. 
    Grove Tool Kit 是针对Grove Develop Component提供的一套.NET Develop Environment的外接程序(Addin) ,能够帮助预览(生成)依赖于Grove组件的可重用代码,包括数据库映射的实体类(Entity Definition Class) ,XML实体描述(XML Definition for data store)等.

作者主页可以了解详情,这是在CodeProject的页面

一起来打太极(2)

了,被锁住了,明天开始卷铺盖到该公司自己的饭店里面入住,要住一个月,一直跟到这个项目结束为止,周六周日也要在那儿加班,好命苦呀。据说那个单位是军工企业,被美军卫星从天上照着,凡在此进入频繁者,不允许入境美国,呜呜呜,明年的MVP Summit参加不了了。

 这两天开始进入详细设计阶段,前段时间,项目组的几位负责人最终与需求方定下了需求,当然,我们在详细设计阶段,还是发现了很多需求不清晰的地方,不过,这种情况经常发生,不是吗?

今天上午搭建了代码编写环境,并且初步分派了任务。共分为三组,一组去进行数据库设计,一组进行业务逻辑层的搭建(含数据层),另外一组进行Web设计。

Web组的成员主要是将前期的实用设计界面(即使用HTML+JavaScript搭建的快速原型)翻译为ASP.NET界面,不过不需要写任何代码,只要把相应的模块转换为ASCX就可以,并且签入到VSS当中。

数据库组的人员按照需求方提供的数据字典建立数据库(数据库系统是Oracle 9i,不知道性能如何),并且建立表间关系、存储过程之类的。

而业务逻辑层组的人员主要搭建实体类及业务操作类,以及数据层,同时为了保证结构优化,数据库组与业务逻辑层组的人员每天要会面一次,讲解一下各自的见解。

为了便于日后的NLB或者CLB的扩展需要,Web层将不会直接调用业务逻辑层的东西,而是通过中间的Web Service进行调用(今天演示了一把Web Service的创建,他们感觉非常酷。因为有人原来是使用Java的,现在对.NET服了,用JBuilder写Web Service,光WSDL文件就让人厌烦)。

现在有几个问题,一直没有想好:

  • 业务逻辑层中的实体类用什么比较好?是创建自定义的实体类还是直接使用DataSet,使用DataSet便于绑定,而使用自定义的实体类则效率较高。那么使用强类型的DataSet呢?会有什么问题吗?需要今天研究决定。
  • 开发过程中如何齐头并进?因为三层结构是纵向分割的,所以会存在相互依赖的关系。难道先是所有人一起上来去做数据层,然后再搭建业务逻辑层,最后一齐完成Web层吗?我不希望这样,所以分为了多组,在两天内不会出现问题,但下周开始,则会有一组人没有事情做。这是我不愿意看到的。
  • 缓存是在页面级做好,还是在业务逻辑层实现好?如何把关键层次的运行效率调整好?前几天看了ASP.NET的那个PPT,然后又去访问了http://www.asp.net,发现并没有像他们鼓吹的有多大的改善,甚至跟CSDN一样,越调整,速度越慢了(CSDN这几天成笑话了)。
  • 如何掌控程序中的Bug?在目前的态势下,根本没有办法按照MS的那一套来做。虽然我提出过可以使用BMS XP来试试,但项目负责人担心如此一来会使项目组的编程方式发生更改(不过也是,光使用VSS我就感觉他们就不习惯了)。

希望有经验的人能够给我一些见解,我也会在后续的过程中把太极十八式打好,供大家参考。

【博客堂杯征文】成就梦想-记我的成长路程(三)

续上

第五部分:技术界面

       有一句古话,叫做兵马未动,粮草先行,强调的是在军事战争中,粮草对于整个战局的重要性。做比赛,或者开发一个项目,就如同打一场战争,里面的粮草,就是我们的技术实力。在创新杯比赛之前,我们团队中所有人对于.net并不是很精通,最多就是能写出一两个中等规模的应用程序。

技术调查可以说是同选题同时开始的,每个人都在努力的学习这.net的最新技术。当然,我们的心理并不害怕,因为我们有最强大的技术支持—-放飞技术网,按我们的话说,就是“如果他们都做不出来的话,也就没人能做出来了”。我也非常相信这一点,正是因为有这样的技术实力,才能把网站办到今天。

界面是这个作品给人的第一种感受,所以界面的设计非常重要。刚开始,每个人必须设计出自己的界面方案,然后拿到一起大家共同讨论。有的设计得像Winamp,有的集成了Windows Office XP的按钮风格,有的设计得像MSN,千姿百态。最后还是一个完整的界面方案得到了大家的认同。


 

       没错,上面两幅图片就是我们当初设计的界面方案。(我没有做任何修改,完全无保留给贴出来的)第一个是一开始画面的Splash窗口,双击桌面图标以后看到的界面。当时的想象是做成MSN的风格,落实到我们这里就是中间的主图标向左上角飞,因为前面还有一个登陆界面,然后一个沉稳的男性声音或者可爱的女生声音同时在说“Checking your password, please waiting.”。窗口中间再有程序的另外图标(比如说那个神殿)在中间旋转或者有其他的动作。第二个是软件的主界面,左下角是旋转的椭圆形轮盘,每个节点代表不同的项目功能,右边主要的那一部分是该部分的详细介绍,对应到每一个介绍中,主界面的左上角会显示相应的详细信息。每次切换轮盘的不同部分的时候,显示界面会出现梦幻般的切换效果,同时配以左下角轮盘的变速旋转。总之所有的所有设计最好能给人一种有下一代应用程序的感觉。界面都是没有边框的,设计的时候考虑最多的是界面美观,完全抛弃技术实现难度。事实证明,这样的决策是正确的。另外还要说一句,我们的项目名称叫做《我的工大.net》,英文名称是《My BUT.net》是解决工大校内信息化的一个应用。

       对于这次的比赛,我们在前期争论最大的就是用什么样的应用。当然焦点只有两个,Web Application 或者 Windows Application,各有各的好处。因为以前我们都是作Web开发出身,或者是做MIS出身,可能对于网页形式的会感觉好一些,毕竟大家都很熟悉。但是考虑到技术实现难度,选题角度,以及一些可拓展型等等,最终我们选择了Windows Application。在这次争执中,我们再次感受到了一个关键的问题,一定要出现能够镇服大家人,或者是理由。那—-是2003年4月。

存储过程之争

ASP.NET项目经理Rob Howard正为存储过程跟人吵架,我基本上同意他的观点,特别是下面这句“You would never put business logic code in your presentation tier, right? Why put ad-hoc SQL in your business logic layer? ”,但好奇的是,ASP.NET 2.0提供了一个SqlDataSource控件,允许你在ASPX页面里直接设置连接字符串/SQL语句(摘自 Check Out The ASP.NET 2.0 Whidbey Features! ):

<asp困惑的笑脸<asp : sqldatasource id=”categoriesSource” runat=”server”
 connectionstring=”server=localhost;database=northwind;uid=sa;pwd=”
 selectcommand=”SELECT * From Categories Where [email protected]”>
  <SelectParameters>
 <asp : ControlParameter defaultvalue=”1″ Name=”CategoryID” ControlId=”CategoryID” PropertyName=”Text”/>
  </SelectParameters>
</asp : sqldatasource>

在 presentation layer里用SQL语句?这是不是有点自相矛盾?笑脸

下一代 Hotmail 初窥

Hotmail 的下一代版本预计在本月发布,让我们提前来看看它漂亮的界面和新功能吧。

新的 Hotmail 的界面和现有的 Hotmail 很象,主要的增强在于减少垃圾邮件。新的界面看起来象在和 Microsoft Oulook Web Access 靠近,虽然右键点击产生的菜单并不相同,但整体界面还是很一致的。并且它允许用户从现有的 Outlook 2000/XP/2003 和 Outlook Express 6 中导入联系人到 Hotmail 中。

新的界面看起来是围绕以垃圾邮件防治为主,从内部测试情况来看,速度很快,这可能是由使用的服务器来决定的,要真正检验其速度,可能要等到正式发布之后了。

截图:Hotmail 今日
截图:收件箱
截图:新邮件
截图:读邮件
来源:Neowin

红烧肉

今天在吃红烧肉,想起以前的一段对话:

翠羽黄衫:我刻了几张碟,真麻烦的说

思归:是么,我刻了一张王菲的,说实话,王菲比那英有才能,好比性格派演员与本格派演员…..

翠羽黄衫:你才发现?

思归:可是王菲太注重配器配乐与发声唱气,每首歌注入的感情成分不多。你如果听听老外的歌手,他们的歌词与音乐都不见得是上佳,但感情饱满。所以我还是不喜欢王菲的歌,笑脸

翠羽黄衫:否也,呵呵。你可能是习惯那英那种感情表达吧。我是觉得王菲感情彭湃

思归:但从歌里听不出来,起码从我录制的那些歌里。王菲与那英好有一比,王菲是黄药师,那英是洪七公,黄药师肯定是比洪七公有才能,但两人都登峰造极

翠羽黄衫:呵呵。我也有一比,那英好比是红烧肉,是家常菜,味道浓烈,王菲是鱼翅燕窝,味道好像很淡,其实回味无穷

思归:也许吧,我喜欢红烧肉,吃不惯鱼翅燕窝

翠羽黄衫:口味问题….

被CDOEXM折磨了一把

下面是我原先用的调用CDOEXM中IMailboxStore接口给用户创建Mailbox的代码:

DirectoryEntry deUser; // deUser为域中的用户
String sHomeMDB; // sHomeMDB为域中Exchange Mailbox Store的路径

CDOEXM.IMailboxStore mailboxStore = (IMailboxStore) deUser.NativeObject;
mailboxStore.CreateMailbox(sHomeMDB);
deUser.Update();

运行到CreateMailbox()这个方法时,Exchange返回来一个“致命性故障”,上面的代码实在是标准得不能再标准的代码,Microsoft在KB中提供的代码示例都是这么几句,郁闷…难道是把DirectoryEntry对象的NativeObject本地对象映射转换成IMailboxStore有问题?

于是,再隔上一层,先转成ADSI中的IADsUser:

ActiveDs.IADsUser adsUser = (IADsUser) deUser.NativeObject;
CDOEXM.IMailboxStore mailboxStore = (IMailboxStore) adsUser;
mailboxStore.CreateMailbox(sHomeMDB);
adsUser.SetInfo();

还是“致命性故障”…于是,Google…终于检索到一个网页,那可怜的哥们和偶一样,也是“Catastrophic failure”,但是好像他比偶聪明那么一点点,他用VB.NET把代码写了一遍,就发现正常了…

就像这样:

Dim oMailboxStore As CDOEXM.IMailboxStore
Dim oADsUser As ActiveDs.IADsUser

oADsUser = GetObject(adsuserPath) ‘ 这里的adsuserPath就是用户的LDAP路径
oMailboxStore = oADsUser

oMailboxStore.CreateMailbox(homeMdb)
oADsUser.SetInfo()

偶再把这段代码在VB.NET里面生成了一个类库,然后在C#中引用、调用,It also works!

但是实在不爽啊…于是盯上了VB.NET中的GetObject()这个函数,暗自想,如果偶在C#里面也调用这个函数…

于是:

IADsUser adsUser = (IADsUser) Microsoft.VisualBasic.Interaction.GetObject(deUser.Path, null);
IMailboxStore mailboxStore = (IMailboxStore) adsUser;

mailboxStore.CreateMailbox(sHomeMDB);
adsUser.SetInfo();

嘿嘿,果真好了!

值得一提的是,VB.NET的类型Late Binding是C#所不具备的,虽然它的意义存在争议,但有些时候的确很有用。

不习惯

用XAML写GUI的编码,用C#写后端的编码时,不用declare控件变量而直接调用,有点不习惯。 前不久看Chris Anderson 和 Don Box的MSDN TV节目,看到他们在后端的编码里直接使用控件变量时,就有一种说不出的感觉。

也许是写ASP.NET写多了,ASPX页面的控件都必须在codebehind宣示才能用,我理解这差异是因为ASP.NET里用的是类继承,而Longhorn里用的partial class合并的方法。在ASP.NET里,page designer和code engineer可以相对独立地工作。code engineer完全可以忽视page里有什么,只要看着类里有什么declare的变量就行了。而在Longhorn/Avalon里,很明显,你需要去研究一下XAML文件里有什么,控件的ID是什么,感觉很麻烦。我原来猜想也许VS.NET会在类视图里帮忙,但在Alpha版的Whidbey里居然没有类视图??

当然,也许写多了,慢慢就习惯了