1)传统的基于存储过程的架构(使用Codesmith的NTiers模板)
3)LINQ To Entity
从上面LINQ到Entity是遥不可及的,因为我们需要非常快速地启动应用程序,并且我们没有相同的技能组,并且团队从未使用过任何OR / M工具,它们将是陡峭的学习曲线(这是我读到的一些地方)
我更喜欢继续使用LINQ to sql(但唯一担心的是微软不会支持或进一步增强LINQ to sql),从我的观点来看,如果微软不打算进一步增强它我没有任何问题,无论如何在我的项目中我需要的功能就足够了.
现在我的问题是我应该使用linq sql还是应该坚持传统架构？
或者其他任何选择都是……
编辑：我将使用sql Server作为数据库,它不需要与任何其他数据库进行交互
设计DAL层的最重要目标之一是为将来的数据库表更改提供更快的开发和可维护性,因为将来可能会增加或减少字段.
此外,如果你觉得任何ORM工具真的很好,并且没有陡峭的学习曲线,那么我们也可以使用
请提供建议
解决方法
使用LINQ to sql的优点：
•没有像SQL查询中那样的神奇字符串
•智能感知
•数据库更改时编译检查
•加快发展
•工作单元模式(上下文)
•自动生成的域对象,它们是可用的小项目
•延迟加载.
•学习编写linq查询/ lambdas是.NET开发人员必须学习的东西.
关于表现：
•在大多数解决方案中,性能最有可能不会成为问题.预优化是一种反模式.如果您稍后看到应用程序的某些区域变慢,您可以分析这些部分,在某些情况下甚至可以使用存储过程或ADO.NET交换一些linq查询.
•在许多情况下,延迟加载功能可以加快性能,或者至少可以简化代码.
关于调试：
•在我看来,对Linq2sql进行调试比存储过程和ADO.NET都要容易得多.我建议您查看Linq2sql Debug Visualizer,它可以让您查看查询,甚至触发执行以在调试时查看结果.
•您还可以配置上下文以将所有SQL查询写入控制台窗口,此处提供了更多信息
关于另一层：
•Linq2sql可以看作是另一层,但它是一个纯粹的数据访问层.存储过程也是另一层代码,我已经看到很多情况,其中部分业务逻辑已经实现到存储过程中.在我看来,情况要糟糕得多,因为您将业务层拆分为两个位置,开发人员更难以清楚地了解业务领域.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
