NHibernate 映射健全性检查

发布于 2024-11-28 03:37:07 字数 490 浏览 2 评论 0原文

目前，我们的新数据库设计正在迅速变化，我并不总是有时间跟上最新的变化。因此，我想创建一些基本的集成测试，这些测试基本上是对数据库映射的健全性检查。

以下是我希望在这些测试中完成的一些事情：

检测我在映射中未定义但存在于数据库中的列
检测我已映射但不存在于数据库中的列
检测我映射的列，其中数据库和我的业务对象之间的数据类型不再相互配合
检测数据库和我的映射之间的列名称更改

我发现以下Ayende 的文章，但我只想看看其他人有什么做来处理这类事情。基本上，我正在寻找涵盖许多映射的简化测试，但不需要我为映射中的每个业务对象编写单独的查询。

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

魂ガ小子 2024-12-05 03:37:07

我对这个测试很满意，它来自 Ayende 提出的测试：

[Test]
        public void PerformSanityCheck()
        {
            foreach (var s in NHHelper.Instance.GetConfig().ClassMappings)
            {
                Console.WriteLine(" *************** " + s.MappedClass.Name);

                    NHHelper.Instance.CurrentSession.CreateQuery(string.Format("from {0} e", s.MappedClass.Name))
                        .SetFirstResult(0).SetMaxResults(50).List();

            }
        }

我使用的是普通的旧查询，因为这个版本来自一个非常旧的项目，而且我懒得用 QueryOver 或 Linq2NH 或其他东西更新......
它基本上 ping 所有配置的映射实体并掌握一些数据，以便查看一切正常。它不关心表中是否存在某些字段但映射上不存在，如果不可为空，则可能会产生持久性问题。
我知道 Fabio Maulo 最终有更准确的东西< /a>.
作为个人考虑，如果您正在考虑改进，我会尝试实现这样的策略：由于映射可以通过 API 浏览，因此在映射中查找任何显式/隐式表声明，并使用标准模式与数据库进行 ping 操作NH 内部的辅助类（它们最终使用 ADO.NET 模式类，但它们隔离了我们在 NH 本身中已经完成的所有配置内容）通过稍微使用命名策略，我们可以实现一个一对一的表字段检查列表。另一项改进可以通过以下方式完成：在字段不匹配的情况下，通过将 Levensthein 距离应用于所有可用名称来寻找候选者，并在满足某些阈值要求时选择一个候选者。当数据库模式由 NH 本身生成时，这在第一类场景中当然是无用的。

I'm happy with this test, that comes from the Ayende proposed one:

[Test]
        public void PerformSanityCheck()
        {
            foreach (var s in NHHelper.Instance.GetConfig().ClassMappings)
            {
                Console.WriteLine(" *************** " + s.MappedClass.Name);

                    NHHelper.Instance.CurrentSession.CreateQuery(string.Format("from {0} e", s.MappedClass.Name))
                        .SetFirstResult(0).SetMaxResults(50).List();

            }
        }

I'm using plain old query since this version comes from a very old project and I'm to lazy to update with QueryOver or Linq2NH or something else...
It basically ping all mapped entities configured and grasp some data too in order to see that all is ok. It does not care if some field exists in the table but not on the mapping, that can generate problem in persistence if not nullable.
I'm aware that Fabio Maulo has something eventually more accurate.
As a personal consideration, if you are thinking on improvement, I would try to implement such a strategy: since mapping are browsable by API, look for any explicit / implicit table declaration in the map, and ping it with the database using the standard schema helperclasses you have inside NH ( they eventually uses the ADO.NET schema classes, but they insulate all the configuration stuff we already did in NH itself) By playng a little with naming strategy we can achieve a one by one table field check list. Another improvement can be done by, in case of unmatching field, looking for a candidate by applying Levensthein Distance to all the available names and choosing one if some threshold requisites are satisfied. This of course is useless in class first scenarios when the DB schema are generated by NH itself.

回复收藏 0 原文