Teddy's Knowledge Base

#1楼  2006-04-25 18:28 idior      

名字不错:)   回复  引用  查看    

#2楼  2006-04-25 18:51 老燕      

给我用用何如?,我笨,以我作为你的框架学习曲线的参照坐标看来是最符合条件了,:)   回复  引用  查看    

#3楼 [楼主] 2006-04-25 19:16 Teddy's Knowledge Base      

@老燕

欢迎尝试~~ ：）

ps：非常欣赏你的《ASP.NET入门随想》的文笔，佩服得没话说~~   回复  引用  查看    

#4楼  2006-04-26 09:02 老燕      

@Teddy's Knowledge Base
我给您留言,请查收   回复  引用  查看    

#5楼  2006-04-26 09:11 装配脑袋      

Bear虽然是那种看起来憨憨的可爱动物——汗，我印象里熊是凶恶的食肉动物。。   回复  引用  查看    

#6楼 [楼主] 2006-04-26 09:51 Teddy's Knowledge Base      

@装配脑袋

"Bear虽然是那种看起来憨憨的可爱动物，但是攻击时身手“敏捷”，"--见笑见笑，我主要要突出后半句来着：）
  回复  引用  查看    

#7楼  2006-04-26 10:04 装配脑袋      

下载下来学习中，看起来挺复杂的阿。
我现在也开始对Emit研究起来，发现讲究还是挺多的。不会的还得向你请教阿
  回复  引用  查看    

#8楼  2006-04-26 10:07 追求卓越      

看到NBear这个名字第一感觉就是：牛B阿。。。
呵呵，一个玩笑，祝你的框架真正的NB。   回复  引用  查看    

#9楼 [楼主] 2006-04-26 10:11 Teddy's Knowledge Base      

@追求卓越，装配脑袋

多谢支持~~ 这个框架离NB还有很多要努力的，现在最大的不足是文档还比较少，暂时只提供了一些Samples和相关的介绍文章，但应该可以参照着使用。另外一点潜在的不足是因为多次较大的重构和组件调整下，现在没有完整功能的UnitTest，不过我会陆续努力加上。希望大家多批评指教！   回复  引用  查看    

#10楼  2006-04-26 10:33 装配脑袋      

我有个小小的疑问哦，为什么DefaultGateway的Update，Get，Select等等方法都必须用显式泛型语法调用呢。这样看上去很不保险的样子   回复  引用  查看    

#11楼 [楼主] 2006-04-26 10:39 Teddy's Knowledge Base      

@装配脑袋

说到泛型，你是老大。你觉得这样主要会有什么不保险呢？
这里主要希望Gateway作为处理任意的强类型和弱类型方式数据访问的Facade，因此，不是所有的方法都需要类型参数，这样，泛型参数就不能给整个类，只能给需要的方法了。   回复  引用  查看    

#12楼  2006-04-26 10:49 装配脑袋      

这就是另外一个疑问了，为什么这些方法都是静态的呢？   回复  引用  查看    

#13楼  2006-04-26 10:54 装配脑袋      

许多东西我还没有弄明白，比如为什么仅仅这样写就成了呢
NBear.Data.Facade.DefaultGateway.SetDefaultDatabase(NBear.Data.Facade.DefaultGateway.DatabaseType.SqlServer, "Server=(local);Database=Northwind;Uid=sa;Pwd=sa");
Response.Write(DefaultCachableGateway.Get<Orders>(10248).ShipName);

他怎么知道我的表就是Orders（难道是从类型名推导？）
我的Orders接口是不是必须按照表结构精确编写？
我是不是只能给Get传入精确编写的类型，或者甚至只能传Orders，这种概念上的约束是何时指定的？   回复  引用  查看    

#14楼 [楼主] 2006-04-26 10:59 Teddy's Knowledge Base      

@装配脑袋

你看得很仔细，只是DefaultGateway的方法是static的，你也可以实例化一个个Gateway，这样就能有多个指向不同数据源的Gateway。

Orders接口可以（建议）由框架工具NBear.Tools.EntityGen.exe生成，表名和字段名是和数据库对应的，不能更改对应（因此减少了很多配置需要，当然是用一定的灵活性换的）。

马上要开会去，回来再解释。总体而言，简单的使用接口，总是要用一些地方的约束来换得的。   回复  引用  查看    

#15楼  2006-04-26 11:13 装配脑袋      

我用泛型的感觉，习惯上认为若方法带有必须显式传递的类型参数（就是尖括号必写的），那就是说类型参数取任何类型都可以，如果要传类型参数，还必须是特别的类型，其他类型都会出错的话，就有不保险的感觉。
我的VBF中也用了这种语法，而且是非常非常不得已才这样做的。所以看到别人这样写的话，我通常会思考是不是有必要这么做。   回复  引用  查看    

#16楼 [楼主] 2006-04-26 12:13 Teddy's Knowledge Base      

@装配脑袋

我觉得如果方法传递类型参数，同时加上约束的话，还是能够保证安全的（编译时就能检查出类型不匹配的错误）。当然，每个方法都要加类型参数确实比较烦，可能的话我还是更喜欢直接将类型参数加到类型而不是方法。   回复  引用  查看    

#17楼  2006-04-26 13:38 装配脑袋      

你这个库编的程序，如果改动数据库的话，哪怕是重命名字段，加新表新关系，代码改动代价似乎也是不小的，你怎么解决这个问题呢。   回复  引用  查看    

#18楼 [楼主] 2006-04-26 13:46 Teddy's Knowledge Base      

@装配脑袋

Entity及字段的的增加和修改可以用框架自带的NBear.Tools.EntityGen.exe生成全部或部分Entity，重命名字段的话我想任何框架都没办法自动帮我们重构的吧？尤其当访问实体字段的代码分布到其他代码时。   回复  引用  查看    

#19楼  2006-04-26 13:52 装配脑袋      

也就是说，你这个库最好还是完全限制在数据访问层内部使用，作为强类型DataSet的一个替代？我是说Data Facade部分   回复  引用  查看    

#20楼 [楼主] 2006-04-26 14:03 Teddy's Knowledge Base      

@装配脑袋

我觉得应该这样理解：如果希望以最安全最小依赖形式来应用这个库，那么，可以向你说的“限制在数据访问层内部使用，作为强类型DataSet的一个替代”，同时，在上层在封装更灵活的Domain层。

但是，更常用的形式是，暴露NBear.Common和你的Entitys到业务层甚至UI层，因为他们是不依赖于数据层的，同时，只在领域层访问NBear.Data.Facade向上返回Entities（当然如果需要更灵活的操作，也可以直接在领域层访问NBear.Data）。

另外一个最简单的应用形式就是不要领域层，直接从UI访问NBear.Data.Facade返回需要的Entities，可以见示例。   回复  引用  查看    

#21楼  2006-04-26 14:51 装配脑袋      

我脑子里出现一种假想的对象持久方案：他像GC一样工作，我的对象完全是我创建的带有业务逻辑的对象，而不仅仅是一堆数据容器（就像DataTable之类的东西）。随着我的操作对象的数据或状态随之变化，而Update，Insert或Delete之类的操作就像GC一样定期执行，同时确保一定的可靠性。   回复  引用  查看    

#22楼  2006-04-26 20:56 eboy.yang      

"...内置的基于Emit的Entity实现，能使您的开发过程更简单，数据读取更高效。"
有没有搞错？用Emit反射还能比直接访问数据更高效？
  回复  引用  查看    

#23楼 [楼主] 2006-04-26 22:54 Teddy's Knowledge Base      

@装配脑袋

你设想的方案还是觉得太理想化了，我觉得下一代SqlServer能够向微软宣传的那样做到数据库级别的实体及关系映射就很不错了，不敢奢求太多。   回复  引用  查看    

#24楼 [楼主] 2006-04-26 22:57 Teddy's Knowledge Base      

@eboy.yang

这里emit的运用并没有降低性能，当然，我说“更”高效的确也不够严谨。不过，这个Entity方案相比Dataset性能会更好，这一点我有测试数据能证明。   回复  引用  查看    

#25楼  2006-04-27 20:59 gozh2002      

我还是有个问题。ENTITY生成类是INTERFACE我觉得并不太好。

因为很多时候，我想在ENTITY上加新的变量，这样子我的ENTITY类就不是一个单纯
的贫血的模型，而是POJO了。

这种情况因该是常出现的吧。如果表中有一个STATUSID，是一个LOOKUP表中来的。
我可以简单的加一个STATUSDESCRIPTION的PROPERTY到我的ENTITY中，方便我
在CLIENT层用。或者我也许想加几个小函数，扩展当前的ENTITY的BUSINESS RULE.

好象因为你现在的实体类都是在EMIT中实现，所以数据类是不是不能改？

另外，我觉得如果ENTITY类还是因该有一个ATTRIBUTE作数据表的COLUMN和ENTIY的PROPERTY对应

我只是有这个疑问，不知道对不对。也许可以扩展吧。

别的方面写的都太好了。赞。
  回复  引用  查看    

#26楼 [楼主] 2006-04-27 21:18 Teddy's Knowledge Base      

@gozh2002

实际上，当Entity由工具生成时，一般是不提倡修改生成的代码的，否则会有潜在的不安全。

关于添加属性和扩展业务规则，我的理解，最好还是独立出来比较好。

另外，Entity的名称和属性是否要一些配置属性来和数据库表灵活映射的问题你说得没错，其实也是我在反复斟酌的问题，加上这样的配置项，自然是有其好处，但是不用这样的配置项则换来使用上的便利（避免了维护映射表），考虑到Entity可以方便的由工具生成，表结构变动是重新生成代码也不难，所以暂时没有加上这样一个映射表，不过就难免的对数据表和字段的名称有一定的依赖，如果，数据库表或字段的名称定义得很不好，可能就会连带造成Entity的名称或字段名称比较难受，不过，大多数数据库设计人员的起名方式应该不止于太过离谱吧。   回复  引用  查看    

#27楼  2006-04-27 22:03 gozh2002      

也对，其实COLUMN MAPPING是不能要的，因为本来就是从数据表生成到ENTITY的。
如果是先有实体类的话，可能就要了。

对于你的ENTITY是INTERFACE, 可能只有再加一个实体类在外面好象FACADE一样。
EM...不过ENTITY LIST怎么办？

我觉得2.0下的代码生成的类是可以大大修改的，因为我们有PARTIAL CLASS。
所有的修改都在外面。

(生成类）
class Student : AbstractEntity
{
string studentName;
int studentStatusID;
}

----------------------------
（扩展属性）
partial class Student
{
public string StudentStatusDescription
get
{
return (string)CacheStudentStatus[this.studentStatusID];
}
}

客户端最常见的就是要显示LOOKUP TABLE中的信息。
如果我把LOOKUP TABLE添到CACHE中， 这样会不会方便很多。
  回复  引用  查看