1

我来自存储过程并手动创建数据访问层。我试图了解我应该在哪里将 Linq To SQL 或实体框架纳入我的正常计划。我通常将业务层与 DAL 层分开，并在两者之间使用存储库。

似乎人们要么使用生成的从 linq 到 sql 的类，通过使用部分类来扩展它们，要么进行完全分离并将生成的 linq 类映射到单独的业务实体。我偏爱单独的商业实体。然而，这似乎违反直觉。

我最近的一个项目使用了 DDD 和实体框架。当需要更新一个对象时，它将业务实体移动到 repistory 层，当进入 DAL 层时，它将创建一个上下文，然后重新查询该对象。它会比更新值和 resbumit。

我没有看到重要的一点，因为数据上下文没有被保存，并且在更新之前需要一个额外的查询来获取对象。通常我会做更新（如果并发不是问题）

所以我的问题归结为：

  1. 将 linq to sql 生成的类分离到业务实体中是否有意义？
  2. 应该保存数据上下文还是不切实际？

感谢您的时间，试图确保我理解。我通常喜欢分开，因为即使在一些较小的项目中也能更清楚地理解。

4

1 回答 1

3

我目前手动滚动我自己的 Dto 类和 Datacontext，而不是使用从 Linq 到 Sql 的自动生成的代码文件。为了提供我的解决方案架构/建模的一些背景，我有一个“合同”项目和一个“Dal”项目。（也是一个“模型”项目，但我会尽量只关注 Dal）。手动滚动我自己的 Dtos 和 Datacontext，使一切变得更小更简单，我将在这里举几个例子来说明我是如何做到的。

我从不返回 Dal 之外的 Dto 对象，事实上我确保将它们声明为内部的。我将它们返回的方式是将它们转换为接口（接口位于我的“合同”层中）。我们将创建一个简单的“PersonRepository”，实现“IPersonRetriever 和 IPersonSaver”接口。

合同：

public interface IPersonRetriever
{
     IPerson GetPersonById(Guid personId);
}

public interface IPersonSaver
{
     void SavePerson(IPerson person);
}

达尔：

    public class PersonRepository : IPersonSaver, IPersonRetriever
    {
        private string _connectionString;

        public PersonRepository(string connectionString)
        {
            _connectionString = connectionString;
        }

        IPerson IPersonRetriever.GetPersonById(Guid id)
        {
            using (var dc = new PersonDataContext(_connectionString))
            {
                return dc.PersonDtos.FirstOrDefault(p => p.PersonId == id);
            }
        }

        void IPersonSaver.SavePerson(IPerson person)
        {
            using (var dc = new PersonDataContext(_connectionString))
            {
                var personDto = new PersonDto
                {
                    Id = person.Id,
                    FirstName = person.FirstName,
                    Age = person.Age
                };

                dc.PersonDtos.InsertOnSubmit(personDto);
                dc.SubmitChanges();
            }
        }
    }

个人数据上下文：

    internal class PersonDataContext : System.Data.Linq.DataContext
    {
        static MappingSource _mappingSource = new AttributeMappingSource(); // necessary for pre-compiled linq queries in .Net 4.0+

        internal PersonDataContext(string connectionString) : base(connectionString, _mappingSource) { }

        internal Table<PersonDto> PersonDtos { get { return GetTable<PersonDto>(); } }
    }

    [Table(Name = "dbo.Persons")]
    internal class PersonDto : IPerson
    {
        [Column(Name = "PersonIdentityId", IsPrimaryKey = true, IsDbGenerated = false)]
        internal Guid Id { get; set; }

        [Column]
        internal string FirstName { get; set; }

        [Column]
        internal int Age { get; set; }

        #region IPerson implementation

        Guid IPerson.Id { get { return this.Id; } }
        string IPerson.FirstName { get { return this.FirstName; } }
        int IPerson.Age { get { return this.Age; } }

        #endregion
    }

您需要将“Column”属性添加到所有 Dto 属性，但如果您注意到，如果您希望在界面上公开的字段与名称之间存在一对一的关联实际的表列，您不需要添加任何命名参数。在此示例中，我在数据库中的 PersonId 存储为“PersonIdentityId”，但我只希望我的界面使该字段显示为“Id”。

这就是我做 Dal 层的方式，我相信这个层应该是愚蠢的，真正的愚蠢。从某种意义上说，它仅用于 CRUD（创建、检索、更新和删除）操作是愚蠢的。所有业务逻辑都将进入我的“模型”项目，该项目将使用和利用 IPersonSaver 和 IPersonRetriever 接口。

希望这可以帮助！

于 2011-03-28T19:08:25.310 回答