我搜索了在某种情况下创建实体的最佳实践。
有一个样本:
我们在数据库中有4个表。
Table Server
id
name
...
Table Environment
id
name
Table Application
id
name
...
Table JCT_Application_Server_Environment
idApplication
idServer
idEnvironment
我们有3个表由1个表链接(JCT_Application_Server_Environment)
我的系统(在asp.net中)需要显示应用程序的“服务器”列表。
那么,我应该使用像这样的实体:
的 V1 的
class JCT_Application_Server_Environment
public idApplication
public idServer
public idEnvironment
并为每个项目加载服务器和环境。 每次加载数据网格都会“困难”。 为了我的目的,我认为这不是好事。
或者更好地创建一个实体:
的 V2 的
class JCT_Application_Server_Environment
public ApplicationName
public ServeurName
public EnvironmentName
你有你需要的东西。 简单,尽量减少。 如果您需要更多,请花更多时间。
如果你有很多属性,那么实体就需要时间。并且每个属性都已在另一个entite(原始应用程序/服务器/环境)中创建。
或者
的 V3 的
class JCT_Application_Server_Environment
public Application //As Application entity
public Server //As Server entity
public Environment //As Environment entity
Sub New(row as datarow) //each New do a GetElementById on Database
me.Application = New Application(row("idApplication"))
me.Server = New Server (row("idServer "))
me.Environment = New Environment (row("idEnvironment "))
首先需要时间加载但是得到你需要的东西,甚至更多。 Datagrid只需知道获取子值(Server.Name/Environment.Name)
第一个主要用于进出口系统。对于webView,它不是我使用的版本,因为我更喜欢在gridview数据库上轻松实现。
第二种情况经常使用,但实体仅用于一件事。 1个gridview的实体。实际情况适合第二个版本。我只是想知道第二次或第三次是否更好。具有.net经验的开发人员可以使用。
如果您有其他选择,可以将其作为答案进行发布。
对于我的实际项目,我决定使用V3,但仅限于容器。数据是由DAL填写。
Dal做类似
的事情function GetList() as List(Of JCT_Application_Server_Environment)
Get List of Application_Server_Environment containing id's
for each item
grab Application, Server and Envirenment by id
create a new JCT_Application_Server_Environment with those 3
add to list of JCT_Application_Server_Environment
return list
答案 0 :(得分:0)
您在此处列出的选项我觉得从以数据为中心的角度来解决问题。您设计的表模式是第3范式(3NF),可以说是是在关系数据库中建模数据的标准方法。
在尝试在应用程序实体中对此进行建模时会出现问题,因为数据在数据库中的建模方式与您希望如何在应用程序中建模数据之间存在阻抗不匹配。 3NF数据建模意味着为了保持一个或多个实体(我将称之为Process
实体,因为它们代表在环境中的服务器上运行的应用程序。将在3个表之间进行内部连接以获取所需数据。除此之外,这三个表中可能还有其他字段,有时我们想要返回,有时我们不想返回(我们可能不需要它们),从而使问题复杂化。
现在我对你的应用程序一无所知,但是看看这个,我倾向于从应用程序(以及实体)为中心的角度对此进行建模。上述问题很大程度上是存在对象关系映射(ORM)框架(如 NHibernate 和 Entity Framework 的原因。现在,这个可以全部映射到一个表,但我有一些问题:
如果这些都是真的,最简单的方法可能是为每个定义enum
并在实体中包含三个枚举
public class Process
{
public int Id { get; set; }
public Environment Environment { get; set; }
public Application Application{ get; set; }
public Server Server { get; set; }
}
然后有一个Processes
表来存储这些值。
如果任何服务器,应用程序或环境发生变化,那么我会问他们有多久会改变?
如果它们不经常更改,则可以继续执行简单的方法并根据需要维护应用程序/数据库。
如果它们经常更改,那么您建议的更加规范化的数据库结构可能就是您的选择。现在您可以编写原始ADO.NET来提取数据,但我建议您查看 Dapper , Simple.Data 或 Massive 以帮助解决此问题,然后将DataGrid绑定到您的实体集合。根据每个表中需要的字段以及所需数据的频率,最终可能会有几种不同类型的稀疏模型来表示数据库中的部分数据,或者您可能选择返回dynamic
类型和< em> know 您可以为给定的上下文访问哪些属性,或者您每次都可以返回完全水合的实体。每种方法都在性能有用性和可维护性方面进行权衡,您选择的方法实际上取决于对应用程序的了解。
我希望我提出一些有趣的问题来思考,并就如何处理这个有点棘手的主题提出一些有用的建议。