62,243
社区成员
发帖
与我相关
我的任务
分享EF Code First模式是否有直接快速编写model的工具
最近在研究MVC，其中有这个CODEFIRST模式 通过实体生成对应的数据库方式；感觉如果有个工具可视化编写输入名称、数据验证、长度之类，然后在生成这个实体代码感觉会快速轻松很多；看书上都是通过手敲代码，太繁琐了。
不知道各位大侠些知道有没有类似工具提供。
不知道各位大侠些知道有没有类似工具提供。
...全文
请发表友善的回复…
发表回复
编程有钱人了 2015-03-02
- 打赏
- 举报
ServiceStack.orm怎么配置数据连接引擎
如何根据现有的表生成实体？？[/quote]
他可以根据实体生成表，或自己手动写实体然后进行自动绑定，不需要什么配置，你看一下他的DEMO就明白了花不到半小时时间。要是EF，你起码要用几天来学习他的配置[/quote]
我看ServiceStack.orm 官网，貌似是收费的[/quote]
4.0以后收费了。不过这东西是开源的。在github下载，接下来 你自己懂的了。
[/quote]
where 条件动态拼接有好的解决方案吗？这个ORM，EF也没有，不过通过lingkit可以解决
[/quote]
where 条件动态拼接有好的解决方案吗？这个ORM，EF也没有，不过通过lingkit可以解决
本拉灯 2015-03-02
- 打赏
- 举报
ServiceStack.orm怎么配置数据连接引擎
如何根据现有的表生成实体？？[/quote]
他可以根据实体生成表，或自己手动写实体然后进行自动绑定，不需要什么配置，你看一下他的DEMO就明白了花不到半小时时间。要是EF，你起码要用几天来学习他的配置[/quote]
我看ServiceStack.orm 官网，貌似是收费的[/quote]
4.0以后收费了。不过这东西是开源的。在github下载，接下来 你自己懂的了。
编程有钱人了 2015-03-02
- 打赏
- 举报
ServiceStack.orm怎么配置数据连接引擎
如何根据现有的表生成实体？？[/quote]
他可以根据实体生成表，或自己手动写实体然后进行自动绑定，不需要什么配置，你看一下他的DEMO就明白了花不到半小时时间。要是EF，你起码要用几天来学习他的配置[/quote]
我看ServiceStack.orm 官网，貌似是收费的
本拉灯 2015-03-02
- 打赏
- 举报
ServiceStack.orm怎么配置数据连接引擎
如何根据现有的表生成实体？？[/quote]
他可以根据实体生成表，或自己手动写实体然后进行自动绑定，不需要什么配置，你看一下他的DEMO就明白了花不到半小时时间。要是EF，你起码要用几天来学习他的配置
编程有钱人了 2015-03-02
- 打赏
- 举报
ServiceStack.orm怎么配置数据连接引擎
如何根据现有的表生成实体？？
yb00k 2015-02-28
- 打赏
- 举报
首先感谢各位，看了各位大神的回复后倍感差距 看来要去研究的东西还挺多的。
不过感觉确实EF这个ORM 有些地方确实很不爽，估计是还没完全吃透熟练的缘故。吃透了自己搞个生成工具来玩！
再次感谢各位参与！
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
不过上述这些其实对我们来说已经毫不重要了，我只是在这里介绍一下至少5年以前我们所知道的 ORM 理念，以及微软的 code first 的实际目标跟其它 ORM 的差距而已。
我们现在只使用 NoSql、无模式的数据库。就这个领域而言，更加不存在什么“可视化工具设置数据库表”的问题。
使用 NoSql 那么你的对象可以直接保存到数据库，而且速度比关系数据库快数十倍（如果对多个字段索引的话，那么速度可能会下降一些）。并且“模式改变”的问题需要自己去处理，数据库也不管了。这就是与面向关系数据库的ORM所不同的另外一种理念了。但是有一点是一致的，就是 code first 编程风格越来越爽，而不是退回到“八股文”阶段。
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
这个就是理念的不同。ORM的理念是：Model代码就是文档，而不是通过数据库表来作为文档，也不是另外再给开发什么软件工程工具输出的文档。
缪军 2015-02-28
- 打赏
- 举报
数据库的表结构的更新不应该导致应用程序的更新,反之亦然:应用程序的更新也不应该导致数据库的更新,
只有设计文档的更新,才会导致应用程序或者或者数据库的更新
哪怕是没有数据库,应用程序组件一样通过测试,
开发工具应该是根据设计文档自动更新数据库或者应用程序,
而无法自动产生的数据库对象或者应用程序对象:比如说复杂的报表,那么设计文档也是可以用来自动化测试这些报表的
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
是的。
种草德鲁伊 2015-02-28
- 打赏
- 举报
我自己写了一个简单的建模工具(非UML，UML不适用)，基于模型可以导出生成任何东西。
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
EF 没有让程序员感觉到类似于 ORM 那样的开发效率，反而使得原本挺好用的 ORM 项目放弃开发了（都以为微软会重点去开发 EF，所以提早放弃了 ORM 开发）。所以说微软的 EF 真的是很害人。
当你写下一个 model 定义，那么数据库表就自动创建了（包括自动进行更新），这本来就是“可执行的文档驱动的数据库定义”。这就不需要让无关的人员（例如dba）去插手初级的开发工作，以此来解决不同角色的人员之间的沟通和衔接问题，避免写多余的文档。
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
ORM解决的是最底层、最傻瓜的化的那个问题，也就是“自动产生数据库表、自动增删改查”的问题。比如说我们有200个model类型，其中80个是用来自动化地去驱动数据库模型的model所以需要“傻瓜化地对应”，另外120个则是需要你自己去写什么“高级的映射”关系的（例如当访问“打开聊天室”功能时，业务逻辑层返回的一个model是将聊天室信息、参与者信息、第一屏幕聊天信息、礼物排序信息等涉及6、7个数据库表的信息综合在一起的一个model）。
这里的关键就是到底需不需要 ORM 的问题。如果说一切增删改查都使用手动写的 SqlHelper 很好地自己写代码完成了，那么就不用 ORM。反之如果说要用 ORM，那么就一定要存在一些跟数据库表一一对应的实体类型。通过这些实体才能做到ORM。
说BLL、model的设计不需要跟数据库表一一对应，那是从系统分析和设计角度。而分析设计之后，到了比较低级的（只占一小部分开发时间的）编码实施阶段，如果我们有一个傻瓜化的开发工具，将效率（特别是每天修改几十遍数据库表定义的效率）提高10倍，这时候还是必要的。
缪军 2015-02-28
- 打赏
- 举报
无论是CodeFirst还是DbFirst都是依赖实现,而不是依赖抽象,说到底ORM还是E-R思想下的数据驱动模式,
只有设计文档才是Code和Db共同依赖的东西,
好的设计文档是可以自动执行的,也是可以自动测试的
software_artisan 2015-02-28
- 打赏
- 举报
其实在我的设计里面，类属性和数据库表并不一一对应。所以，无论是code fast还是 db fast，都不是我需要的。我需要的是一个能够提供更高级的映射的功能，而不是简单到愚蠢的一一对应。
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
由于记录有Register过的每一个数据库关联实体类型的信息签名 --> 由于记录有Register过的每一个数据库关联实体类型的信息签名已经在数据库中
以专业开发人员为伍 2015-02-28
- 打赏
- 举报
在我们以前的代码中，（例如）只要定义
public class ABC
{
public int X;
public DateTime Y;
public string Z;
public DEF u;
public HG[ ] v;
} Db.RegisterType(typeof(ABC));var query = from x in Db.RemoteTable<ABC>() where x.u.Name=="张三" select x;编程有钱人了 2015-02-27
- 打赏
- 举报
不是有自带的吗？根据数据库表自动生成
yb00k 2015-02-27
- 打赏
- 举报
可以这么理解，PD没用过，搜索了下感觉使用起来挺复杂的！
娃都会打酱油了 2015-02-27
- 打赏
- 举报
你不觉得这样就是在建立数据库吗？？？
PD满足你的需求啊
加载更多回复（6）
