C# 实体类与数据库之间的关系 用工具生成或自定义一个实体类对应数据库中的某张表的字段,通过数据库连接字符串就能直接映射到这张表吗? 解决方案 » 免费领取超大流量手机卡,每月29元包185G流量+100分钟通话, 中国电信官方发货 去网上下载一个动软.net 代码生成器..很简单的..后台实体类,基本上都是自动生成的. 这个过程需要人为控制!实现实体类与DataTable之间的数据转换! 楼主,你写的那个叫做:DataModel,不是Entity,entity = The existence of something considered apart from its propertiesEntity是:剥离了具体属性的客观存在,Entity不存放任何数据相关的字段,而描述的是职责 本来我还想让LZ看看db first ,model first,code first相关知识点,却发现LZ想把硬币直接变成饮料,而这个过程却不需要一个魔法师 看你怎么理解了,如果那做菜来说数据库可以看成原材料供应库 或 配菜中心商务逻辑实体基本可以 厨房+大师傅UI可以看成服务员+跑堂传菜+结账通常来说我们说实体有两个语境“商务逻辑实体”和“数据实体”他们的区别是一个是厨房+大师傅处理的,另一个是不经过厨房+大师傅处理滴直接就端过去的生菜你说你愿意上生菜,俺这里是自助烧烤,客户想吃啥自己现做,那也未尝不可,到另外是种特色。比如当年的delphi就是这种自助烧烤型的,快速,多变,味道想怎么配就怎么配,当然盐放多了,或着东西没弄熟也是你自己的事情。 关于实体,我不知道你这个解释是从哪里得到的。我的理解是,实体这个词,从本源上说,是表示实实在在存在的个体。它说明了实体的最重要的2个特性,一个是它实实在在存在,也就是它是具体的,反映真实存在的概念。另一个是个体,表明实体必须是独立存在的。在面向对象的设计时,实体的概念被引申为直接参与序列化的原子类。可以被持久化对应的是它的存在性。而原子类,表明它的独立性。再推而广之,什么样的类符合这样的标准呢?抽象类、不包含属性的类、由程序管理,但是不参与序列化的类,由基本类组合而成的类,业务逻辑,这些都不符合,大致地说(注意,大致这个词),用途上的实体类,和形式上的(POCO类,简单对象),是一致的。Entity Framework中的Entity一词,也是这个意思。所以大多数人说的Entity,代指POCO,没有什么大错。但是DataModel和Entity是两回事,DataModel未必具有Entity的原子性。 Entity是剥离了具体属性的客观存在,这和OOAD里面的Entity本质是不冲突的。但是形式是不同的。这就好比,“用户”和程序中的“用户对象”,表示的都是同一个概念,但是程序中的“用户对象”是对现实“用户”这个概念的抽象。 根据我的理解,我来站在microtry的角度来描述一下,如果有什么不对,请microtry指正。用户Entity不关心用户是否有用户名或者是否有密码,而只关心用户是否有登录功能或者是否有注册功能。所以Entity是生成不出来的,生成出来的只能是DataModel,而且一个Entity对应的也许不仅仅是一个DataModel。比如有User与Manager两个表格,细节虽然不同,但Entity可能就只有一个了。 这种描述更像在User Case Diagram中的Actor。为什么用Entity描述它呢? 感谢14楼肖进的回复,大概意思差不多,我的做法是这样:1.并不是OOAD的结果都由编程实现,有的是通过存储实现,有的是通过组织策略实现;2.比如:我把Logon看作AppCenter的职责,而把用户信息的CURD看作Ordinary的职责 AppCenter负责任何Employee,Customer,Supplier登录任何应用的处理 Ordinary负责任何“简单的CURD”的数据对象的处理 而这些都不依赖数据表格,我们可以在多个项目重用相同的实体,而数据结构可以大相径庭,这是由设计文档决定,跟实体无关 顺便说一句,关于entity的解释不是我发明的,也不是软件开发者发明的 求帮忙看看部署mvc3出错,急。。。 vs2010出现的问题 如何在Form中建一个自己设计的对话框?? C# 值类型OR引用类型? 自定义控件问题 请问c#里面写留言板一般用什么样的方法? [WebMethod]中鏈結出錯!!!!!!! c#中如何调用matcom? FileStream问题,求助 线程操作的问题(不解) 问一个有关重定向输出和WaitForExit函数的问题
很简单的..
后台实体类,基本上都是自动生成的.
entity = The existence of something considered apart from its properties
Entity是:剥离了具体属性的客观存在,
Entity不存放任何数据相关的字段,而描述的是职责
用户Entity不关心用户是否有用户名或者是否有密码,而只关心用户是否有登录功能或者是否有注册功能。
所以Entity是生成不出来的,生成出来的只能是DataModel,而且一个Entity对应的也许不仅仅是一个DataModel。
比如有User与Manager两个表格,细节虽然不同,但Entity可能就只有一个了。
1.并不是OOAD的结果都由编程实现,有的是通过存储实现,有的是通过组织策略实现;
2.比如:我把Logon看作AppCenter的职责,而把用户信息的CURD看作Ordinary的职责
AppCenter负责任何Employee,Customer,Supplier登录任何应用的处理
Ordinary负责任何“简单的CURD”的数据对象的处理 而这些都不依赖数据表格,我们可以在多个项目重用相同的实体,而数据结构可以大相径庭,这是由设计文档决定,跟实体无关