没有ORM的数据访问层

Question

我正在编写一个MMORPG服务器仿真器（爱好项目），现在遇到了数据访问层的问题。由于性能问题，我不能使用ORM。我已经阅读了很多关于仓储模式的文章，但似乎并不适用于我的项目，因为我需要像 (player db) GetAllByLevel(...)，GetByName(...)等方法。我希望我的应用程序具有数据库不可知性（目前正在使用SQL Server，但稍后我想加入对MySQL的支持）。哪种数据访问模式适合我的项目？

抱歉我的英语不太好。

编辑

还有一个问题。我读到过仓储模式是基于聚合根操作的。我有3个表：player、player_friend 和 player_chest。Player是聚合根，如果我没错的话，我应该只创建一个仓库（PlayerRepository），它可以拥有像 GetFriends([player id], ...)、GetChest([player id], ...) 等方法。是这样吗？

- RlyDontKnow

---

如果使用得当，ORM 的开销可以忽略不计：你的关系型数据库将是最慢的部分。从ORM开始，如果发现它会拖慢性能，随时可以将其删除。 - Sergey Kalinichenko

正如@dasblinkenlight所指出的那样，过度优化是一个不好的想法。只有在运行了一些性能测试并且可以证明使用ORM会对你造成问题时，才应该放弃使用ORM的想法。 - Steve Mayne

谢谢大家。我很感激你们的帮助。不过，我会继续使用纯 SQL（因为我正在学习 TSQL），而且我已经编写了大部分查询。为了简化操作，我会使用 Dapper 微 ORM。:p - RlyDontKnow

你错了。ORM 可能是一个重要的问题 - 大多数 ORM 做了很多事情，这是有代价的。我可以建议 OP 看看 BlToolkit，它是一个“浅层 LINQ 提供程序”，没有性能成本更高的操作，我们在 ETL 场景中成功地使用了它，每秒发出约一百万个 SQL 语句。 - TomTom

也许你应该考虑删除你的编辑，并针对聚合根问题创建另一个问题。你应该尽量在每个帖子中提出一个单一的问题，并尽可能具体。 - julealgon

哇，考古学家 :D 这个问题是去年的。; p - RlyDontKnow

Answer 1

我读了很多关于仓储模式的内容，但它似乎不太适用于我的项目，因为我需要像 (player db) GetAllByLevel(...)、GetByName(...) 等方法。

恰恰相反。有很多错误的仓储模式示例（通常是不完整的抽象），教你错误的东西。GetAllByLevel 在我看来是一个好方法，因为它清楚地描述了该方法的作用。

我写过关于仓储模式的文章：http://blog.gauffin.org/2013/01/repository-pattern-done-right/。还请阅读文章开头的抽象链接。

问题在于我不能使用 ORM（性能问题）。

没问题。仓储模式用于抽象数据源，无论其类型如何。

如果您想使用原生 ADO.NET，可以阅读这篇博客文章：http://blog.gauffin.org/2013/01/ado-net-the-right-way/ 另外一个问题。我读到仓储模式是在聚合根上操作。我有 3 张表 player、player_friend 和 player_chest。Player 是一个聚合根，如果我没错的话，我应该只创建一个仓储库（PlayerRepository），可以拥有像 GetFriends([player id], ...)、GetChest([player id], ...) 这样的方法，我对吗？

不是。我会说 Friends 也是根节点。阅读有关设计聚合的文章：http://dddcommunity.org/library/vernon_2011

- jgauffin

---

谢谢回复。我会查看你发的链接。 - RlyDontKnow

Answer 2

仓储库是正确的选择。关键在于您可以拥有相同仓储库接口的多个实现，一个用于SQL Server，另一个用于Oracle或PostgreSQL。您不一定需要一个支持所有可能数据库的通用实现（这将非常困难）。

具体实现可以使用任何具体DBMS的特定功能来满足您的性能标准。

- Wiktor Zychla

---

是的，我知道。问题在于我读过仓储模式不应包含像 GetAllByLevel、GetByName 等方法。 - RlyDontKnow

而且？你不需要ORM来实现这些方法。Repository可以使用ORM或不使用ORM来实现。 - Wiktor Zychla