ORM架构

Question

背景:我有一个大规模的项目(2个ASP.NET Web应用程序,每个类似10页).这两个Web应用程序共享许多后端需求,特别是操作一组约50个表的能力.它们都是同一个RDBMS,它总是MySQL.

问题:一段时间后,项目中添加了一个功能丰富的大型ORM库(Subsonic),结果证明它太多了.它太大了,零件太多了,开销太大了.由Subsonic生成的一些集合需要> 1分钟来创建,而原始内联查询(我知道很糟糕)可以完成同样的需要~2s.这不仅仅是Subsonic的问题,NHibernate和其他ORM工具太大了,太多的功能永远不会被使用.这些项目的范围也永远不会变得很大.数据库不可知也是不必要的,因为我们永远不会从MySQL切换,除了内部,没有人会使用这个工具.

显然内联查询很糟糕,不安全,错误.Linq也不是一个选择.因此,需要一些小的自定义ORM工具供我打包在库中.我的想法是包括:

• 基础是一个Table类,它的构造函数只是一个db名称和一个表名
• Table类会公开公开一些方法
• public DataRow Record(string primaryKeyValue)//获取单个记录
• public DataRowCollection Records(string whereClauseOrRangeOfKeyValues)//获取记录集合
• public bool Save()//通过更新/插入已更改的任何行来保存数据库的当前状态; 不确定维护哪些记录是否脏的最佳方法
• public bool Loaded(string primaryKeyValue)//告诉给定记录是否存在
• public DataRowCollection Query(string mysqlQuery); //运行特定的自定义查询
• 私下里几乎只有几件事:一个消毒剂,一个选择的方法,一个做upserts的方法,而不是其他的东西

也许StackOverflow的汇集知识可以突出这个基本设置的缺点或提供改进.提前致谢.

编辑:一个约束(不确定它在这一点上是多么坚定)是我没有使用预先构建的库.亚马逊关闭了更高的产品,任何第三方实用程序都可能被拒绝.因此,与实用程序选择相比,它更像是一种架构选择.

Answer 1

在开始制作自己的工具之前,您应该检查Micro ORM,例如:

• 短小精悍的
• 海量

那里很少有其他人.