Question

考虑以下类结构。

public class Employee
{
    public int EmployeeId { get; set; }
    public string Name { get; set; }
    public int CompanyId { get; set; }
}
public class Company
{
    public int CompanyId { get; set; }
    public string Name { get; set; }
}
public class User
{
    public Employee Employee { get; set; }
    public Company EmployeeCompany { get; set; }
}

当我构建Company类时，我使用以下SQL查询（存储过程）传递给以下构造函数。

SELECT  CompanyId ,
        Name
FROM    dbo.Companies

private Company BuildCompany(SqlDataReader reader)
{
    return new Company()
    {
        CompanyId = ConvertFromDbValue<string>(reader["CompanyId"]),
        Name = ConvertFromDbValue<string>(reader["Name"])
    };
}

我使用以下SQL查询（存储过程）来获取用户信息。

SELECT  EmployeeId ,
        e.Name AS EmployeeName ,
        c.CompanyId ,
        c.Name AS CompanyName
FROM    dbo.Employees AS e
        JOIN dbo.Companies AS c ON e.CompanyId = c.CompanyId

我使用别名来区分两个Name列。现在我需要使用此查询构造一个User类。我想最大化可重用性，所以我试图重用现有的公司构造函数，但是返回的列名不同，显然不起作用。

那么我应该创建一个只处理别名列的新构造函数吗？我应该只是在User构造函数中初始化一个新的Company对象并直接映射属性吗？是否有第三种选择可扩展性和可重复使用？

Answer 1

如果这是您构建Company：

的方式

private Company BuildCompany(SqlDataReader reader)
{
    return new Company()
    {
        CompanyId = ConvertFromDbValue<string>(reader["CompanyId"]),
        Name = ConvertFromDbValue<string>(reader["Name"])
    };
}

如果这是技术要求所规定的方法（如对问题的评论中所讨论的那样），那么为什么不重复相同的模式来构建User？

private User BuildUser(SqlDataReader reader)
{
    return new User()
    {
        Employee = new Employee()
        {
            EmployeeId = ConvertFromDbValue<string>(reader["EmployeeId"]),
            CompanyId = ConvertFromDbValue<string>(reader["CompanyId"]),
            Name = ConvertFromDbValue<string>(reader["EmployeeName"])
        },
        Company = new Company()
        {
            CompanyId = ConvertFromDbValue<string>(reader["CompanyId"]),
            Name = ConvertFromDbValue<string>(reader["CompanyName"])
        }
    };
}

它不像ORM那么漂亮。但它是一贯的，可支持的。任何尝试创建一个更通用的解决方案只是为了减少代码中的击键将带来一些耦合。由您决定是否值得减少击键次数。根据我的经验，这很罕见。

SQL结果在结构上非常不同，并且不是由对象模型驱动的。（例如，Employee数据结果中Company和User个对象之间存在重叠。）这本身并不是坏事，因为它允许随着域复杂性的增加，进一步进行SQL端优化。但它确实排除了通用方法，而是倾向于手动方法。再说一次，本身并不是件坏事。但最好通过维护相同的手动模式在代码中明确地公开它。

除非引入复杂性是一个非常令人信服的理由，否则我会在简单性和重构方面犯错误。

如何从具有不同签名的过程构造类

1 个答案: