7

假设您在一家不允许使用任何类型的 ORM 工具的 IT 商店。他们不想购买，您也不能使用开源解决方案。

你会怎么做？放弃真正的领域模型和以工作表为中心？制作自己的 DAL？

4

14 回答 14

12

严格来说，您的选择是：

  1. 不要使用关系数据库
  2. 不要使用 OOP 语言

否则某种 ORM 解决方案是不可避免的（即使你自己推出，它仍然是一个简单的 ORM 层）。

于 2009-03-05T18:57:16.377 回答
9

Based on your username, I'd say "use LINQ." It's built into .NET and it's not an ORM (strictly speaking).

于 2009-03-05T19:20:47.413 回答
9

选项：

  1. 自己滚
  2. 退出
  3. 无论如何都要使用开源的，不要告诉他们，在原型运行良好时向他们展示原型，然后让他们重新考虑开源。
于 2009-03-05T18:51:30.307 回答
6

如果您确实无法使用现有的 ORM 之一，那么我不建议您创建自己的 ORM。本地种植的 ORM 往往是半实施、设计不佳、长满疣的野兽，在前六个月似乎有所帮助，然后逐渐成为项目中最耗时的问题。

如果您应用 Fowler 的企业应用程序架构模式中的“RowDataGateway”或“TableDataGateway”等模式，则可以不使用 ORM。

您最终仍会发展自己的隔离层以将您的域与数据库分开，但创建它不会像滚动您自己的 ORM 那样昂贵。

于 2009-03-05T19:29:12.977 回答
5

There are three possibilities here:

  1. Your bosses don't understand the benefits of using an ORM.
  2. Your bosses are doing things the way they always have done things and won't consider changing.
  3. Your bosses have valid reasons for not choosing an ORM.

More than likely though, it's a combination of these three things. They probably have valid concerns that could be cured through better understanding of ORMs. My advice is to try selling them on ORMs. Find a particularly nasty piece of code that could be cured by using an ORM and make a prototype that shows how much that code could be simplified. Also, be willing to compromise.

If they're not willing to budge on this, you need to ask yourself if this is really a place you want to work. Not because they won't let you use ORMs (which you could probably live without), but because they won't listen to you. You can't always have your way, but you should have input on the development process.

于 2009-03-05T19:08:59.767 回答
4

If it's about the company being too cheap to buy one, then write your own, and at the end of the project show them the cost in terms of your time. (I assume they're against free alternatives on principle)

If it's about performance, you might have to check whether they have a point.

If they worry that it adds a layer of complexity which other developers will have to learn, then show some examples of code simplified with the ORM.

If it's because the application is already very "table-centric" you'll also have to think whether adding an ORM will improve things or just add a lot of unnecessary mapping complexity.

(Oh, and read this : http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx )

于 2009-03-05T19:18:56.793 回答
4

我会推出我自己的 DAL，使用类似于Generic DAO的东西来抽象它，这样我的代码的其余部分就不会紧密耦合，但我正在获取数据。

如果它们稍后出现，这使得将其全部交换到 ORM 变得很容易。

于 2009-03-05T18:51:53.147 回答
3

制作你自己的 DAL，就像我们在很久以前，很久以前...... 2004 年所做的那样。

于 2009-03-05T18:53:33.547 回答
2

First off, it's absolutely retarded that you can't even use an open source one.

If you have to roll your own, it's not a huge deal. You can still have domain models just fine. You might have an easier time if you model each record, and then build the domain models to load data from that as an intermediate format.

于 2009-03-05T19:04:11.900 回答
1

See what they think about iBatis (http://ibatis.apache.org/) which isn't an ORM but helps you get objects from database queries without inscrutable ORM magic, lots of XML though.

How are they doing things now?

于 2009-03-05T19:21:41.000 回答
1

我会推出自己的解决方案，可能会使用某种代码生成工具。从技术上讲，如果您将结果（无论是数据读取器、表格、记录集还是其他）转换为您的对象，您就有一个小的 o/r 映射器，非常缺乏但仍然......我猜这是定义问题。

我的主要目标是避免在我的代码中重复 CRUD，这需要时间，很无聊并且是缺陷的来源。

如前所述：如果不需要关系数据库，您总是可以使用一些对象数据库。但是那些更不常见，如果你的老板反对 orm:s 他不太可能这样做。

于 2009-03-05T20:05:10.847 回答
0

询问为什么不允许使用 ORM，什么构成 ORM，然后从那里决定两种可能性中的一种：

  1. 交易
  2. 没有交易（退出）
于 2009-03-05T18:54:39.253 回答
0

如果你决定构建我们自己的 DAL，Davy Brion有一个很好的教程。
查看构建您自己的数据访问层系列。

于 2011-04-06T06:27:18.123 回答
-4

“没有任何类型的 ORM 工具。他们不想购买，你也不能使用开源解决方案。”

没有任何类型的 ORM或者只是开源/$$$？

优秀的 ORM 工具有免费版本：

于 2009-03-05T19:37:11.913 回答