数据访问MVC3
问题： 我正在构建（或尝试构建）企业级网络应用程序的前端。现有结构由存储过程（sql 2008 db）驱动。存储过程被实现为最终处理执行的类，并且结果作为对象返回。 我是这个游戏的新手，欢迎解释如何最好地利用我的时间...我读到的存储库模式是最佳实践，但我读到的所有示例都实现了 Entity Framework 或 Linq 等...do我需要一个 ORM 吗？为什么或为什么不？我希望能够拥有一个最高性能的环境，以便用户可以使用这些结果集。提前致谢
question:
i'm building (or trying to build) a front end for an enterprise level web-app. the existing structure is driven by stored procedures (sql 2008 db). A stored proc is implemented as a class that ultimately handles the execution and the results are returned as an object.
i'm new to this game and would welcome an explanation about how my time would best be served...i read a repository pattern is a best practice, but all of the examples i read implement Entity Framework or Linq, etc..do i need an ORM? why or why not? i'd like to be able to have a maximum performance environment so that users can play with those result sets. thanks in advance
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
好吧，我建议决定您的用例。
nHibernate / ORM 通常不擅长的一些事情是：
，如果您的工作主要涉及其中任何一个，那么您最好不要浪费时间，也就是说，拥有多种策略并没有什么问题......构建域模型对于简化复杂的业务规则非常有用，性能通常是也非常好...报告和批处理作业可以单独构建，没有理由不同的策略不能共存...但是我会尽力使它们分离...
所以如果你有一个毛茸茸的大业务逻辑层，它是如果您的存储过程中散布着数据集/数据访问代码和业务逻辑，那么您可能会发现值得花时间投资 ORM，但请考虑将其视为重构步骤...即，您正在改进现有代码并使其成为可能在扩展之前可测试...
无论如何，没有一个“最佳”答案，我在以前的公司所做的最明智的事情就是以任何似乎有意义的数据访问模式构建新功能（当然是测试驱动）功能...保持界面干净和解耦...这样做一段时间后，通常会很明显哪种策略/模式最适合整个应用程序...
祝你好运
Well, I would suggest deciding on your use cases.
Some of the things that nHibernate / ORM's generally are not good for are:
So if your work primarily involves either of those then you're best off not wasting your time, that being said there's nothing wrong with having multiple strategies... Building out a domain model is great for simplifying complex business rules, performance is generally very good too... Reporting and batch jobs can be built out separately, there's no reason why the different strategies can't co-exist... I woul however do my best to keep them decoupled...
So if you've got a big hairy business logic layer and it's littered with datasets / data access code and business logic IN your stored procedures then you will likely find it worth your while to invest in an ORM, but consider it a re-factoring step... IE you're improving existing code and making it testable before extending it...
In any case there's no one 'best' answer, the smartest thing I've done at previous companies has been to build new functionality (Test driven of course) in whichever data access pattern that seems to make sense to the functionality... Keep interfaces clean and decoupled... After doing that for awhile it usually becomes obvious which strategy / pattern is best suited for the application overall...
Good luck
你的问题有点不清楚。存储过程是存储在数据库中的 SQL 查询，用于与数据交互。然而，听起来您已经有一个现有的数据访问层（DAL），它使用存储过程并将对象返回给您使用。如果是这样的话，我不会丢弃整个数据访问层并用 EF 或任何其他 ORM 替换它。除非现有的 DAL 由于设计或性能原因而无法为您工作，否则没有理由重新发明轮子。
Your question is somewhat unclear. Stored Procedures are SQL queries stored on the database which are used to interact with the data. However, it sounds like you already have an existing data access layer (DAL) which uses stored procedures and returns objects to you to play with. If this is the case, I would not throw away the entire data access layer and replace it with EF or any other ORM. Unless the existing DAL isn't working for you for either design or performance reasons, there's no reason to reinvent the wheel.