数据访问层的好方法是什么？
我们的软件是一个定制的人力资源管理系统（HRMS），使用ASP.NET和Oracle作为数据库，现在我们实际上正在努力使其成为一个支持多个租户拥有自己的数据库的产品。
我们的选择：
使用NHibernate来支持多个数据库和OO的使用。但我们关心NHibernate的学习曲线和我们面临的任何问题。
创建一个通用的 DAL，它将继续使用存储过程与 Oracle 配合使用，并使用工具将其转换为其他数据库，例如 SQL Server 或 MySql。必须支持单个脚本的多个依赖于数据库的版本存在风险。
提供软件即服务 (SaaS) 并维护我们开展业务的方式。但是，可能有些客户不想要或不信任云或其他 SaaS 业务模型。
考虑到这一点，最好的数据访问层技术是什么？
Our software is a customized Human Resource Management System (HRMS) using ASP.NET with Oracle as the database and now we are actually moving to make it a product that supports multiple tenants with their own databases.
Our options:
Use NHibernate to support Multiple databases and use of OO. But we concern related to NHibernate learning curve and any problem we faced.
Make a generalized DAL which will continue working with Oracle using stored procedures and use tools to convert it to other databases such as SQL Server or MySql. There is a risk associated with having to support multiple database-dependent versions of a single script.
Provide the software as a Service (SaaS) and maintain the way we conduct business. However there can may be clients who do not want or trust the Cloud or other SaaS business models.
With this in mind, what's the best Data access layer technique?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
我建议您花时间学习 NHibernate，它有许多用于查询和更新数据库的选项，使其与数据库无关，这意味着您只需在 HQL 中编写一组脚本。
我会推荐《Nhibernate by Example》，这是一本可以帮助您入门的优秀书籍。
I would advise you spend the time and learn NHibernate it has a number of options for Querying and updating databases that make it database agnostic, this means you would only have to write 1 set of scripts in for example HQL.
I would recommend Nhibernate by Example it is an excellent book to get you going.
我想说 NHibernate 乍一看令人印象深刻，而且学习起来似乎非常复杂。因此，在快速阅读了大约 260 页的介绍文档，并坚持了我需要在测试应用程序中执行的任务后，NHibernate 确实是我的最佳选择。如果您对 XML 映射文件不感兴趣，只需使用 FluentNHibernate，它允许您使用 OOP 进行映射您的业务域对象。
此外，如果您对 NHibernate 不太熟悉并且更喜欢采用其他方式， Enterprise Library 4.1（2008 年 10 月） 可能是一个有用的工具。根据具体情况，在某些组织中，我选择了 NHibernate - Enterprise Library 的混合方法。企业库中的数据访问应用程序块 (DAAB) 非常容易学习，除了您已经知道的知识之外，不需要您学习任何内容。您只需要知道使用什么对象从 DatabaseProviderFactory 类创建 DbConnection 来从配置文件中读取，并且您可以指定默认数据库。
至于我的担忧，我经常使用 NHibernate 和 Enterprise Library。例如，DAAB 允许我为每个配置文件指定一个数据库连接，因为我更喜欢为每个文件仅指定一个连接参数。这允许我不必为根本没有更改的配置部署不必要的配置文件，而只为另一个连接部署新的配置文件。因此，如果您合并一个必须连接到另一个数据存储的新模块，则您可以构建模块而无需关心其余部分，并使用模块的 DLL 以及这个新的 DAAB 配置文件来更新您的软件。
对于 NHibernate，不要做的一件重要的事情是当您不再需要 ISessionFactory 时将其删除。实例化的成本很高，因此您希望将其保留在内存中。不过，您可以做的是序列化您的配置对象类（因为它是可序列化的），因此只有当您的 NHibernate 配置文件发生某些更改时，您的应用程序才能构建其配置。再说一次，我建议您使用 NHibernate 的默认 hibernate.cfg.xml 配置文件，这样您就不需要在更新时一遍又一遍地部署 app.config 文件。
我希望这有帮助！如果您需要更多信息，请告诉我。
I would say that NHibernate is impressive at first view and seems very complex to learn. Therefore, after reading the about 260 pages introduction document rapidly, and having insisted on the tasks I needed to perform within the tests applications, NHibernate is really the way to go. And if you're not enchanted with the XML mapping files, just use FluentNHibernate which allows you to use OOP for mapping your business domain objects.
Furthermore, if you're not completely at ease with NHibernate and prefer going another way, Enterprise Library 4.1 (October 2008) might either be a useful tool. Depending on the situation, in some organizations, I have opted for an hybrid of NHibernate - Enterprise Library approach. The The Data Access Application Block (DAAB) within Enterprise Library is quite easy to learn and doesn't require you to learn anything but what you already know. You just need to know what object to use to create your DbConnection from the DatabaseProviderFactory class to read from your configuration files and you may specify a default database.
As for my concerns, I often use both NHibernate along with Enterprise Library. The DAAB allows me for example to specify a database connection per configuration file since I prefer to parameter only one connection per file. This allows me not to deploy unnecessarily config files for configs that didn't change at all, and only deploy THE new configuration file for another connection. So, if you merge a new module that must connect somewhere else to another datastore, you build your module without caring about the rest, update your software with your module's DLL along with this new DAAB config file.
As for NHibernate, an important thing not to do is to get rid of the ISessionFactory when you no longer need it. It is costful to instantiate, so you want to keep it in memory. What you can do though is the serialize your configuration object class (as it is Serializable), so your application can build its configuration only if something changed into your NHibernate config file. Then again, I suggest you use the default hibernate.cfg.xml configuration file for NHibernate, this way you won't need to deploy your app.config file over and over again when updates come.
I hope this helps! Let me know if you need further information.
我们有类似的场景“HRM + ASP.NET + 多数据库支持”，我们选择了 MyGeneration 的 dOOdads 架构，该产品已经发布并且运行得很好！
只需在 google 上搜索 MyGeneration，您就可以开始了！
关于 SaaS：是的，许多客户不会接受将数据存储在云上，无论其安全性如何。在市场上享有声誉后，您可以说服其中一些客户。因此，第一阶段重点关注支持“内部部署”作为高优先级、SaaS 作为第二优先级的设计。如果“内部部署”不可行，您最好咨询 SaaS 营销顾问。
We had a similar scenario "HRM + ASP.NET + multi DBs support" and we chose MyGeneration's dOOdads Architecture and the product already released and working pretty well!
just google for MyGeneration and you'll be ready to go!
Regarding SaaS: yes many clients won't accept to have there data on the cloud no matter how secure its. you could convince some of these clients after having a reputation in the market. so in the first phase focus on a design that support "in-house deployment" as high priority and Saas as second priority. if the "in-house deployment" not an option you better consult SaaS marketing consultant.
对于任何需要支持多个数据库供应商的大型项目（超过 20 个表？），使用 NHibernate 几乎肯定比定制 ORM 更便宜（从开发成本和学习曲线的角度来看）。我不知道如何回应您列表中的第 3 项，因为我不知道如何将您今天所做的事情与使用 NHibernate 进行比较。有可能无论您今天所做的事情实际上都比 NHibernate 更好，但您在这方面没有提供足够的信息。将自己锁定在基于技术决策的特定业务模型中是一个危险的业务决策，而以后撤销的成本可能会很高。
Using NHibernate is almost certainly going to be cheaper (from both a development cost and learning curve perspective) than a custom built ORM for a project of any significant size (more than 20 tables?) that needs to support multiple database vendors. I don't know how to respond to item 3 on your list because I don't know how to compare whatever you are doing today to using NHibernate. It's possible that whatever you are doing today is in fact better than NHibernate, but you have not provided enough information in that regard. It's a risky business decision to lock yourself into a specific business model based on a technology decision which could be expensive to undo later.
我会选择#3，因为这可以让你尽早进入市场，并有望开启强劲的收入来源。与提议的产品相比，客户更愿意资助将现有的成功产品转换为独立系统。您还将从真实用户那里获得宝贵的反馈，从而改进产品。您可能会发现不需要独立系统。
如果您是从头开始，我建议您学习 NHibernate。
I would go with option #3 since that gets you to market earliest and hopefully starts a robust revenue stream. Clients will be much more willing to fund converting an existing successful product to a stand-alone system than a proposed product. You will also get invaluable feedback from real users that will improve the product. And you may find that there isn't demand for a stand-alone system.
If you were starting from scratch I would suggest learning NHibernate.
我认为这一切都取决于优先事项！
根据我的经验，我总是会考虑这样一个事实：系统的任何部分都可以更改，因此至少总是会记住系统如何与其他数据库一起工作并继续前进。
明确地采用您最了解的内容，然后在您有时间和金钱时进行调整/重构。您可以在开发后续组件时引入 NHibernate/IOC，然后返回并重构。
I think it all depends on priorities!
In my experience is that I would always consider the fact that any part of a system can be changed and therefore would always at the least have in mind how the system would work with other databases and move forward with that.
Clearly go with what you know best and adapt/refactor later when you have the time and money to do so. You could introduce NHibernate/IOCs in later components as you develop them and then go back and refactor.