NBear V3.3.6使用感受

    NBear是博客园组织的第一个开源项目,创始人是Teddy's Knowledge Base,NBear的目标是通过吸收园子里很多朋友的开发经验和智慧,发展成为一个优秀的.NET开发框架,帮助大家提高开发效率,让大家的工作更加轻松。
    今天,我准备在实际开发中使用NBear,但试用了后,觉得操作上有点复杂,需要进一步改进。
当我们使用NBear设计一个新的实体类时,我们需要进行以下的操作:
1、 在实际开发项目之外,创建一个新的实体设计项目(该项目只在设计时有用)。
2、 新建一个实体类进行设计。
3、 添加对NBear的引用。
4、 添加对实际项目的引用。
5、 设计实体元数据。
6、 编译。
7、 通过NBear.Tools.EntityDesignToEntity.exe生成实际的实体类(该实体类与设计时的实体类相差很大,增加了很多为了ORM而增加的代码)。
8、 在实际项目中,新建一个实体类文件。
9、 添加对NBear的引用,
10、 添加对实际项目的引用。
11、 将生成的实体类的代码复制到实体类文件中。
12、 通过NBear.Tools.EntityDesignToEntity.exe生成实体类的xml配置。
13、 将生成的实体类的xml配置复制到EntityConfig.xml中。
14、 在web.config中添加section与entityConfig配置。
15、 通过NBear.Tools.EntityDesignToEntity.exe生成创建数据库表的脚本。
16、 在数据库中创建数据库表的脚本。
17、 配置连接字符串。
18、 调用Gateway访问数据库。

当我们更改实体类的设计,即使是某个属性的类型,我们需要进行以下操作:
1、 打开实体设计项目。
2、 更改实体类的设计。
3、 通过NBear.Tools.EntityDesignToEntity.exe生成实际的实体类。
4、 用生成的实体类的代码覆盖来原来的实体类代码。
5、 通过NBear.Tools.EntityDesignToEntity.exe生成实体类的xml配置。
6、 用生成的实体类的xml配置覆盖原来EntityConfig.xml中相应的配置。
7、 手动修改数据库中相关字段。

我觉得理想的操作应该是:
设计一个新的实体类:
1、 在实际开发项目新建一个实体类进行设计。
2、 添加对NBear的引用。
3、 添加对实际项目的引用。
4、 设计实体元数据。
5、 配置连接字符串。
6、 调用Gateway访问数据库:在Gateway中,如果发现实体类对应的表不存在,自动根据实体类创建数据库表,在运行时自动生成原先通过NBear.Tools.EntityDesignToEntity.exe生成的代码(这只是想法,技术实现上的难度目前还不清楚)。

更改实体类的设计时:
1、直接在实际项目中打开实体类进行修改。

另外我觉得NBear可以提供一个轻量级的数据映射功能,假如已经设计好了实体类、数据库表、相应的存储过程,可以提供这样的调用方法:Gateway.Save<实体类>(实体类的实例,存储过程名称),通过存储过程操作数据,不用自动生成SQL语句,有时用户需要利用存储过程在性能和复杂查询上的优势。

posted @ 2006-11-21 22:08 dudu 阅读(5021) 评论(21)  编辑 收藏

  回复  引用  查看    
#1楼 2006-11-21 22:25 | JerryZhao      
同感,尤其是在设计实体类的时候,要输入的代码繁琐,可否考虑设计一个NBear toolbox 内迁入vs, 如果可以用鼠标选取元数据添加就好了
  回复  引用    
#2楼 2006-11-21 22:27 | .progame [未注册用户]
我的方案是:

1、设计实体类和关系
2、用dbconnection初始化我的session
3、自动创建数据库结构
4、操作
  回复  引用    
#3楼 2006-11-21 22:29 | .progame [未注册用户]
类和关系的设计相当简单直观:
class Domain_Order:Table
{
public Field<Guid?> OrderID;
public Field<string> OrderNo;
public Field<DateTime?> OrderDate;
public Domain_Customer Customer;
public Domain_Customer Agent;
public Field<string> Remark;

[Composited]
public ChildList<Domain_OrderItem> Items;
}
  回复  引用  查看    
#4楼 2006-11-21 22:34 | 菌哥      
我觉得一对一,一对多,多对多这样的实体间的关系由NBear.Tools.DbToEntityDesign.exe工具自动生成,这样的话开发起来要快得多.我今天做了一个数据库,才八个表,有点表除了自连接,本身还有外键,而且上面还有父表,这样的实体间的关系设计起来我觉得很有难度,如果能根据数据库的结束自动生成这些关系就好了
  回复  引用  查看    
#5楼 2006-11-21 22:50 | wqxh      
这次一个小新闻系统我使用了NBear框架。从易用性上来说我觉得做的还是不错的,但由于是新的框架,确实还存在一些bug,而且我觉得Gateway中的方法还是缺少了一些,所以一些看来比较常用的数据库操作变得要使用DbHelper(不知道是不是我没有找到),同时也希望作者能够完善一下帮助文档。总之,这个框架我觉得还是很好用的,效率则有待考验
  回复  引用  查看    
#6楼 2006-11-22 01:59 | Henry Liang      
看过NBear的原码,感觉Teddy真是在里面下足了功夫,首先赞一个!不过我也有一个考虑,就是在设计框架的时候,是不是要把一切的一切都包容进去,使得框架变成一个“万能工具”,似乎不太可能,毕竟软件的需求千变万化——我的考虑是,能否将NBear变成一个松散的框架集合,每一个子框架都侧重某一方面的功能,就想Enterprise Library那样。同时,这样的分散也有助于开源项目多人协同工作。一点浅见,欢迎大家用鸡蛋砸我。
  回复  引用  查看    
#7楼 2006-11-22 08:28 | junmy      
就是觉得 当 修改实体类时 ..还又要重新生成一遍太麻烦了...



  回复  引用  查看    
#8楼 2006-11-22 08:35 | 菌哥      
@wqxh,
NBear中有DbHelper
  回复  引用  查看    
#9楼 2006-11-22 08:39 | Teddy's Knowledge Base      
谢谢大家的建议。

关于易用性方面的改进,我的想法,最好的办法是写一个VS插件,能够在设计实体修改时自动更新实际的实体代码、实体XML配置和数据库中的表结构,这样就能避免每次小修改时的重复的代码生成过程的人工劳动。

@菌哥
从数据库到实体的设计方法,个人不太推崇,因为数据库本身的描述能力有限,而且往往相同的数据库表、字段结构,在OO模型中的含义可能是不同的,当然,可能的情况下,尽可能加强目前的DbToEntityDesign.exe工具的能力,让他获取更多数据库中可以获取的元数据,还是应该是未来努力的目标之一。

@Henry Liang
你说得没错,其实目前,NBear的各个组件之间耦合不大,Data,IoC,Web都是可以独立使用的。

  回复  引用    
#10楼 2006-11-22 08:48 | xjb922@gmai.com [未注册用户]
太复杂了 搞这么复杂 怎么用啊 还不如 直接的。~!!!!!!!!!!!!!
  回复  引用    
#11楼 2006-11-22 09:29 | 小鬼[匿名] [未注册用户]
还是简单点.直接点好.灵活.
  回复  引用  查看    
#12楼 2006-11-22 09:45 | Henry Liang      
谢谢Teddy指正。上面两位的评论,有点!@#$%了吧?
  回复  引用    
#13楼 2006-11-22 09:49 | 随风.NET [未注册用户]
简单的是否可以用2.5版本的?
  回复  引用  查看    
#14楼 2006-11-22 10:05 | Teddy's Knowledge Base      
@随风.NET
V2.5当然还是可用的。

@All
下一版本预计将会增加VS插件,隐藏这些繁琐的手工代码生成细节,和现有的版本完美兼容。暂时嫌麻烦大家每次修改实体,手工生成一下代码,使用将来的版本时也将无需改动已有代码的。
  回复  引用  查看    
#15楼 2006-11-22 11:04 | MK2      
@Teddy's Knowledge Base
呵呵,目前已经对NBear上手了````很多之前想的问题,可以转个弯,就实现了,而且一句SQL脚本都不会出现`````但要适应这种方式,还是需要时间的。
  回复  引用    
#16楼 2006-11-22 13:49 | 是 [未注册用户]
还是不太会用,比较吃力
  回复  引用  查看    
#17楼 2006-11-24 08:47 | apan      
如果能拟订一个详细的模块开发任务,会更能提升大家的能力。建议dudu承揽一些任务,进行分工,每个模块小组也需要进行更细的分工。
  回复  引用  查看    
#18楼 2007-09-25 17:24 |       
微软提供了dataset的对象化,提供了反射。为什么要受到java的思想约束了?
  回复  引用  查看    
#19楼 2008-01-20 16:38 | heize_lee      
差不多都这意思.都是这些步骤...能量守恒定律啊....封装的好了.灵活性肯定下降..
  回复  引用    
#20楼 2008-04-26 14:40 | roland [未注册用户]
你的blog的字的颜色太浅,看起来不舒服

标题  
姓名  
主页
Email (只有博主才能看到) 
验证码 *  看不清,换一张 [登录][注册]
内容(请不要发表任何与政治相关的内容)  
  登录  使用高级评论  新用户注册  返回页首  恢复上次提交      
该文被作者在 2006-11-22 10:45 编辑过


相关链接: