我将教授一个类sson,我需要解释哪些因素会影响您对数据访问技术的决定。 我熟悉许多数据访问方法,如Typed Data Sets,Linq to SQL,Linq to Entities,.netTiers,LLBLGen,以及使用SQL连接对象和命令对象的自定义调用。 我的一些客户只允许使用存储过程,他们不会讨论其他任何事情。 我的一些客户尚未准备好安装.NET 3.5。 某些客户端需要在任何Web应用程序中使用中间Web服务层。 大多数时候我使用类型数据集和自定义Web服务,或者我使用.netTiers和CodeSmith。我还应该考虑什么?
答案 0 :(得分:3)
要记住的一件重要事情是数据库不一定只是应用程序的后备数据存储(孤立地)。其他应用程序和进程最终可能需要访问数据库,尤其是在大型或“企业”数据库(或应用程序)中,特别是在有足够时间的情况下。
重要的是要考虑:
此外,还需要考虑一些设计因素。您是在调整更快的选择还是更快的写入?一种数据访问设计可能比另一种更好。
我并没有说明只有一颗银弹,但我要注意的是,任何数据访问设计模式都需要“全局”思考 - 它会解决今天的问题以及你可以合理预测的可能是明天的需求?
另外,您是否会提供外部API或某些框架以实现一致的数据访问?是直接还是间接暴露?
我认为,实体框架/ LINQ to SQL,传统存储过程和NHibernate等其他工具都有一席之地,但你应该首先证明并合理化技术的选择,并尝试确保它是适合当前和未来的需求。
编辑:对不起,我忘记了重要的一点:可维护性。一些模板驱动的解决方案为您提供了一些体面的胜利,能够在架构更改后重新生成DAL,而不是其他(如手写存储过程)。值得权衡生产力增长与劣势。答案 1 :(得分:2)
与软件项目中的所有选择一样:它取决于...... 但在我看来,最重要的因素是项目的环境。
这包括(我不认为此列表完整无效):
希望这会对你有所帮助。
答案 2 :(得分:1)
我认为在您的原始帖子和norbertB的添加内容之间,您已经涵盖了所有内容。从绝对约束开始(记住,这只是因为客户对某事说不 - 即使他们说这是绝对的 - 这并不意味着你无法改变他们的想法......)。一旦你用绝对约束缩小了领域,就要看看其他事情。
似乎遗漏的一件事是灵活性。例如,如果我试图在两种类似的技术之间进行选择,我知道可以支持可更新的视图,而另一种则不能,即使我当时完全不需要可更新的视图,我仍然会倾向于那个“以防万一“。
答案 3 :(得分:0)
我真的只想到两件事。首先是我是否会拥有其他重要的数据。如果您没有将数百万行放入表中,那么您将要使用哪种技术并不重要,因为它们都能够快速地工作。
第二件事是我是否可以使用LINQ,因为我发现使用LINQ(对SQL,实体,LLBLGen,无所谓)查询数据库给你两件重要的事情。第一个是编写查询非常容易,其次,在需要更改的情况下,在两个需要LINQ的框架之间切换是相当容易的。