C# 实体类与数据库之间的关系

Question

用工具生成或自定义一个实体类对应数据库中的某张表的字段，通过数据库连接字符串就能直接映射到这张表吗？

Answer 1

去网上下载一个动软.net 代码生成器..
很简单的..
后台实体类,基本上都是自动生成的.

Answer 2

这个过程需要人为控制！实现实体类与DataTable之间的数据转换！

Answer 3

楼主，你写的那个叫做：DataModel，不是Entity，
entity = The existence of something considered apart from its properties
Entity是：剥离了具体属性的客观存在，
Entity不存放任何数据相关的字段，而描述的是职责

Answer 4

本来我还想让LZ看看db first ，model first，code first相关知识点，却发现LZ想把硬币直接变成饮料，而这个过程却不需要一个魔法师

Answer 5

看你怎么理解了，如果那做菜来说数据库可以看成原材料供应库 或 配菜中心商务逻辑实体基本可以 厨房+大师傅UI可以看成服务员+跑堂传菜+结账通常来说我们说实体有两个语境“商务逻辑实体”和“数据实体”他们的区别是一个是厨房+大师傅处理的，另一个是不经过厨房+大师傅处理滴直接就端过去的生菜你说你愿意上生菜，俺这里是自助烧烤，客户想吃啥自己现做，那也未尝不可，到另外是种特色。比如当年的delphi就是这种自助烧烤型的，快速，多变，味道想怎么配就怎么配，当然盐放多了，或着东西没弄熟也是你自己的事情。

Answer 6

关于实体，我不知道你这个解释是从哪里得到的。我的理解是，实体这个词，从本源上说，是表示实实在在存在的个体。它说明了实体的最重要的2个特性，一个是它实实在在存在，也就是它是具体的，反映真实存在的概念。另一个是个体，表明实体必须是独立存在的。在面向对象的设计时，实体的概念被引申为直接参与序列化的原子类。可以被持久化对应的是它的存在性。而原子类，表明它的独立性。再推而广之，什么样的类符合这样的标准呢？抽象类、不包含属性的类、由程序管理，但是不参与序列化的类，由基本类组合而成的类，业务逻辑，这些都不符合，大致地说（注意，大致这个词），用途上的实体类，和形式上的（POCO类，简单对象），是一致的。Entity Framework中的Entity一词，也是这个意思。所以大多数人说的Entity，代指POCO，没有什么大错。但是DataModel和Entity是两回事，DataModel未必具有Entity的原子性。

Answer 7

Entity是剥离了具体属性的客观存在，这和OOAD里面的Entity本质是不冲突的。但是形式是不同的。这就好比，“用户”和程序中的“用户对象”，表示的都是同一个概念，但是程序中的“用户对象”是对现实“用户”这个概念的抽象。

Answer 8

根据我的理解，我来站在microtry的角度来描述一下，如果有什么不对，请microtry指正。
用户Entity不关心用户是否有用户名或者是否有密码，而只关心用户是否有登录功能或者是否有注册功能。
所以Entity是生成不出来的，生成出来的只能是DataModel，而且一个Entity对应的也许不仅仅是一个DataModel。
比如有User与Manager两个表格，细节虽然不同，但Entity可能就只有一个了。

Answer 9

这种描述更像在User Case Diagram中的Actor。为什么用Entity描述它呢？

Answer 10

感谢14楼肖进的回复，大概意思差不多，我的做法是这样：
1.并不是OOAD的结果都由编程实现，有的是通过存储实现，有的是通过组织策略实现；
2.比如：我把Logon看作AppCenter的职责，而把用户信息的CURD看作Ordinary的职责
  
   AppCenter负责任何Employee，Customer，Supplier登录任何应用的处理
   Ordinary负责任何“简单的CURD”的数据对象的处理   而这些都不依赖数据表格，我们可以在多个项目重用相同的实体，而数据结构可以大相径庭，这是由设计文档决定，跟实体无关

Answer 11

顺便说一句，关于entity的解释不是我发明的，也不是软件开发者发明的