1

考虑一个由 100 多个表组成的数据库（MSSQL 2005），这些表在一​​定程度上定义了主键。表之间存在“关系”，但是这些不是通过外键约束来强制执行的。

考虑以下我正在处理的典型表格类型的简化示例。User 与 City 和 Province 表之间有明确的关系。但是，它们的关键问题是表中的数据类型和命名约定不一致。

User:
    UserRowId [int] PK
    Name [varchar(50)]
    CityId [smallint]
    ProvinceRowId [bigint]

City:
    CityRowId [bigint] PK
    CityDescription [varchar(100)]

Province:
    ProvinceId [int] PK
    ProvinceDesc [varchar(50)]

我正在考虑重写使用此数据源的应用程序（在 ASP.net MVC 中），因为它的设计类似于MVC 店面。但是，我正在经历概念验证阶段，这是我遇到的绊脚石之一。

  1. 就可以轻松使用的 ORM 选择而言，我有哪些选择，为什么？

  2. 我什至应该考虑 ORM 吗？（我问这个的原因是大多数解释和教程都适用于设计相对干净的现有数据库，或者与我相比是新创建的数据库。因此，我很难找到解决这个问题的方法）

  3. 有大量现有的 SQL 查询，数据映射器（例如 IBatis.net）是否更合适，因为我们可以轻松地修改它们以使其工作并重用已经进行的投资？

我在 SO 上发现了这个问题，它向我表明可以使用 ORM - 但是我觉得这是一个映射问题？

注意：目前，对象模型没有明确定义，因为它不存在。现有系统几乎用 SQL 完成几乎所有事情，或者由过于复杂和大量查询组成以完成功能。我几乎是一个菜鸟，并且在 ORM 和 MVC 方面的经验为零 - 所以这是一个很棒的学习曲线。

4

3 回答 3

1

我同意本。

我在这种情况下使用了 LAMP 堆栈。一个旧的肮脏、糟糕的编码网站需要重新开始。它实际上是我见过的最糟糕的数据库，再加上一行又一行的盲目 SQL 执行。

工作？快速摆脱所有 SQL 并用抽象替换它。哪个ORM？我发现回顾性地使用现有的 ORM 来适应坏数据库（实际上是大多数数据库）是个坏消息。我认为这是 ORM 的一个问题，它们将数据库/存储问题移到更靠近应用程序的位置……而不是更远的地方。

我的解决方案：一个只使用现有数据库状态来计算发生了什么的反射 ORM。所有选择、插入、更新和未使用的视图/存储过程来掩盖粗糙的数据库。它由一个 linq-esque API 提供支持，只需用它重写严峻的 SQL。将大约 100klocs 的 SQL 语句归结为小于 2klocs。

优点：我可以逐渐将数据库移植到视图和程序后面的更好结构。恕我直言，这就是所有数据库的组织方式，充分利用 SP 和视图提供的抽象。我从不想看到直接针对表的单个 SQL 语句（或伪装成 SQL 的 ORM）。

这就是我的故事。一种过度设计的方法，在现有的垃圾数据库之上插入一个很好的抽象，无需先重写数据库，也无需将 ORM 混入其中，从而使事情变得更加复杂。

毫无疑问，这是一个 hack，但它工作得很好，我在可以从头开始设计数据库的项目中使用它；）

于 2010-05-13T19:52:18.673 回答
0

尝试保留现有模式然后将其转化为更结构化的 orm 模式所涉及的工作量可能会很大且很复杂。如果您正在重写整个系统并淘汰旧系统，那么我将设计我的数据模型创建一个新的数据库和一组类，也许使用 linq2sql，然后编写一个数据迁移脚本将数据从旧模式移动到新模式. 这样，您复杂的繁琐代码都在迁移中，您不必处理维护和管理结构化类模型和设计不良的数据库之间的复杂映射。

于 2010-05-13T19:26:49.823 回答
0

我们刚刚遇到了一个糟糕的架构设计问题（随机有主键，根本没有外键，设计糟糕的表 - 只是一团糟）。

我们拥有丰富的技术选择，并且采用了 MVC2 前端（与您的问题无关），并且有 2 个开发人员分开 - 一个尝试使用 NHibernate 建模，另一个使用 Entity Framework 4。

我赶紧补充一点，我们对我们想要从我们的域模型中得到什么有一个强烈的想法，并首先对其进行建模（不希望受到数据库的约束），所以从模式的角度来看，我们的“用户”对象实际上跨越了 5 个表，我们封装了很多业务逻辑，这样域模型就不会错了，一旦我们对我们的 User 对象感到满意，我们就开始尝试插入 ORM 的过程。

我可以毫不犹豫地说，在这两种情况下（NH 和 EF4），我们必须在模型上做出妥协才能硬着头皮实施，这是惊人的。我将为您提供 EF4 中的示例，因为这是我最密切参与的示例，其他人可能能够将这些与其他 ORM 相关联。

私人二传手

不，EF4 不会影响您的生活。您的属性必须是公开的。有一些解决方法（例如，围绕来自您的数据库的属性创建包装器）

枚举

同样，不 - 有一个包装器概念和一个“映射”来尝试从数据库中获取查找 int 到模型枚举类型中。

结果

我们用这两种方法坚持了一段时间，以达到我们完成用户映射的地步，结果是我们不得不以太多方式破坏我们的域模型。

在那之后我们去了哪里？

Linq to SQL 与我们自己的映射层。而且我们从未回头——非常棒——我们自己编写了映射层，将 Dto 对象放在 Dal 层并将其映射（如我们指定的那样）到我们的域模型中。

祝你对 ORM 的任何调查都好运，如果我有一个像样的模式来作为它们的基础，我肯定会重新调查它们，但就目前而言，使用糟糕的模式，更容易推出我们自己的模式。

干杯，特里

于 2010-05-14T15:24:16.707 回答