数据库模型转向面向对象设计

本文关键字：面向对象设计 数据库模型 | 更新日期: 2023-09-27 18:01:36

如何在c#中设计类来表示数据库模型?

给定一个数据库的下列表和字段，

表:员工 

Pk EmpID
   Lname
   Fname
   Adress
Fk DeptID
<<p> 表:部门/strong> 
Pk DeptID
   DeptName
   Location

现在我想在c#中创建两个类，一个用于Employee，一个用于Department。最让我头疼的是外键。我应该在对象的设计中使用外键，还是应该在Department的Employee类中放置一个引用，或者应该在Department类中放置一个员工引用列表，还是应该两者都做?我知道如果我使用外键，效率会降低，因为我将不得不搜索与外键匹配的主键列表，但我可能应该在设计中包含它们。

数据库模型转向面向对象设计

不要在对象中使用"外键"。使用引用;每个部门都应该有一份员工名单。根据您是否需要将Employee反向引用到其部门，确定Employee是否将引用到Department。

阐述@Paul Sonier的回答…

注:我在一般意义上使用业务层， 业务类，而不是作为某些特定技术设计模式的术语。

使用数据库键的具体问题
为了使对象和数据库保持同步，使用数据库键会导致大量的编码开销。当需要添加、更改、删除对象时(通过用户GUI)，您将像疯了一样跳圈。当父对象还不存在于数据库中时，如何创建子对象?想象一下，尝试用任何n级数据结构来做这个。

始终设计业务类而不考虑数据存储
业务层类应该忠实地反映业务规则、术语、概念和上下文。从长远来看，用有关存储或显示数据的细节等非商业内容污染这个"创意空间"是不好的。现在听我说，以后再相信我。

基于某些特定数据库表布局(以及它的键等)的业务类将使编写用于验证规则、创建这些对象的适当状态等的代码变得极其困难。这是在保持对象id与数据库同步的问题之上。

最大限度地解耦业务层和数据层
你问题中的例子是一个诱人的骗局。您的一些业务类可能非常适合您的数据库设计。因此，主键和外键似乎也很合适。

BUT 在任何重要的应用程序中，数据库模型都会偏离。如果不是现在，就是以后。出于数据库完整性、效率和速度的考虑，它会有所偏差。这和商业模式有什么关系?什么都没有。

指示你做的事情是正确的

  1. 您可以实例化一个业务对象而不需要现有的数据库

  2. 每个对象都可以引用它的"子对象"，而不需要在业务类模型之外创建特殊的键。

  3. 每个业务对象在它自己的上可以验证、执行、标记等等所有它自己的规则，甚至是像"不能为空"这样微不足道的规则。复合类/对象的业务规则验证是类设计;分析活动-不是数据库设计活动

首先，如果可能的话，我建议使用像NHibernate、实体框架或Linq to SQL这样的工具来为你做对象到关系映射。但是，如果你不想这样做，我可能会这样设计我的对象模型:

public class Employee
{
    public int Id { get; set; }
    public string LastName { get; set; }
    public string FirstName { get; set; }
    public Address Address { get; set; } 
    public Department Department { get; set; }
}
public class Department
{
    public int Id { get; set; }
    public string Name { get; set; }
    public Address Location { get; set; }
    public ICollection<Employee> Employees { get; set; }
}

我不想过度简化，但是如果你有Employee => Department或Department => Employee的导航属性，这是非常特定于你的应用程序的需要的。

然而，根据经验，我倾向于将导航属性从层次结构的顶部向下放置。这意味着我将拥有Department。雇员，但不是雇员。各部

同样，这是特定于您的，但您似乎不太可能需要从每个Employee获取Department对象。因此，在Employee类中使用键进行查找就像这样:

class Employee {
    public int[] DepartmentIds { get; set; }
    public List<Department> Departments {
        get {
            return YourStaticReference.DepartmentList
                .Where(x => this.DepartmentIds.Contains(x.DepartmentId));
        }
    }
}
看到了

?祝你好运!

相关文章：