DAO/Repository/NHibernate 和处理边缘数据库案例
一直困扰我的一件事是如何在一个真正不属于 DAO 或存储库管辖范围的系统中处理数据库操作，而且我在书籍/博客中没有看到太多提及。我喜欢使用通用 DAO/存储库的方法来处理常见的数据库操作，但是处理非实体的事物又如何呢？例如，假设我正在构建一个系统，在某些情况下我需要调用存储过程来运行批处理操作并仅返回成功代码。或者，我只需要从杂项表中加载日期。或者，我想从表中加载美国各州的列表。这些情况确实会发生，并且它们实际上可能与系统中的实体或其他对象没有任何关系。在不放弃令人讨厌的“杂项”数据库类（放弃 NHibernate 之类的东西来手动使用 ADO.NET 来执行这些类型的操作的情况下），OOP 人群中还有哪些其他标准方法？
One thing that keeps stumping me, and I do not see much mention of it in books/blogs, is how to handle DB operations in a system that really don't fall under the jurisdiction of DAOs or Repositories. I like using the approach of generic DAOs/Repositories to handle common DB operations, but what about dealing with things that aren't entities? For example, say I am building a system and in a few cases I need to call a stored procedure to run a batch operation and just return a success code. Or, I need to just load a date from a miscellaneous table. Or, I want to load a list of US states from a table. These cases certainly do occur and they really may not have anything to do with an entity or other object in the system. Without dropping in a nasty "misc" DB class that forgoes something like NHibernate to manually use ADO.NET to do these types of operations, what are some other standard approaches from the OOP crowd?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
绕过 DAO 并直接使用 ADO 连接器（或本机驱动程序）正是每个人都会做的事情，并且没有什么“令人讨厌的”或错误的。如果这些对您来说确实是边缘情况，那么您期望什么样的框架？更糟糕的是，当人们对他们的 DAO 进行各种奇怪的恶作剧，仅仅以“不绕过<在此插入 DAO>”的名义做一些糟糕的事情时。
我的意思是，如果您有一个存储过程，那么您显然已经认为数据库不可知论已经被排除在外（无论如何，这是一个被高估的目标），那么为什么对使用 ADO.Net 心存疑虑呢？只要在代码中非常明确地表达出来即可，不要隐藏它。自豪地大声说“我正在使用数据库，我不在乎任何人的想法！”。哦，请确保它仍然与您的其他逻辑分开。我不希望我的单元测试因为你的存储过程而变慢。
Bypassing the DAO and working directly with the ADO connector (or native driver) is exactly what everyone does, and there is nothing "nasty" or wrong about it. If these are indeed edge cases for you, then what kind of framework would you expect? What is worse is when people wrap all kinds of weird shenanigans around their DAO to do something it sucks at just in the name of "not going around <insert DAO here>".
I mean if you have a stored proc, then you have obviously decided that DB agnosticism is out the window (it's a overrated goal anyway) so why have misgivings about using ADO.Net? Just make it very explicit in the code, don't hide it. Say it loud and proud "I'm using the database, and I don't give a flick what anyone thinks!". Oh and please make sure its still seperated from the rest of your logic. I don't want my unit tests to get slow because of your stored proc.