在构建在其数据访问层中使用实体框架的Web应用程序时,建议从对象上下文中分离对象以允许对象进行垃圾回收.
但由于Web应用程序都是请求 - >响应应用程序,因此在将响应发送给客户之后,任何活动对象都不再引用对象上下文本身,因此对象上下文及其附加对象应该可用于垃圾回收,因为没有活动对象引用它们中的任何一个.
我在这里错过了什么或在这种情况下不需要分离对象吗？
我们正处于设计具有多个模块的大型业务应用程序的早期阶段.其中一个要求是应用程序应该独立于数据库,它应该支持SQL Server,Oracle,MySQL和DB2.
根据我在网上看到的内容,数据库独立性是一个非常糟糕的主意:它会导致难以维护的代码,数据库设计在所有受支持的DBMS中具有最不常见的功能,性能差和可扩展性差.我个人的直觉是,这个功能的复杂性,比任何其他功能更多,可能会以指数方式增加开发成本和时间.代码将是可怕的.
但我不能说服任何人忽略这个功能.问题是关于这个问题的大多数数据都是经验数据,缺乏支持案例的数字.如果有人可以在这个问题上分享任何数字支持的数据,我将不胜感激.
其中一个可能的设计选项是将Entity框架用于数据库层,并为每个DBMS使用提供程序.我个人的感觉是,在没有任何ORM的情况下手动编写SQL语句将是"必须",因为您无法控制实体框架生成的SQL,并且独立于数据库的场景需要基于DBMS进行一些SQL调整,代码是定位,我认为第三方实体框架提供商将有大量的错误,这些错误只出现在应用程序将具有的复杂场景中.我希望听到之前有过使用实体框架进行数据库独立场景的经验的人.
此外,团队讨论的一种可能性是在第一次迭代中支持一个DBMS(例如SQL Server),然后在连续迭代中添加对其他DBMS的支持.我想,既然我们需要一个数据库的设计与最常见的功能,这一发展战略是不好的,因为我们需要知道的所有数据库的所有功能之前,我们开始第一个DBMS编写代码.我也需要听听你关于这种可能性的消息.