我有一个VB WinForms项目,我们使用Entity Framework 6 Code First。我知道在Web应用程序中限制dbContext(我们通过存储库类间接使用)的生命周期是理想的做法,但我最近了解到,通常情况下,对于WinForms项目,你应该在表单的生命周期内保留一个dbContext。
假设我有ClassA和ClassB两个类,所有ClassA对象都有一个可选的ClassB对象(以及EF6用作外键的相关“ClassBId”属性)。我们有一个名为ClassAForm的窗体,供用户编辑和查看ClassA对象,并且自然地显示一些有关其ClassB对象的信息;这个ClassB应该是ClassA专属的,但也可能在其他表单上查看。这个表单上有一个按钮,打开另一个名为ClassBForm的表单,允许用户编辑和查看ClassB对象。ClassBForm不是模态的,当前也没有向生成它的ClassAForm传递任何内容,尽管ClassAForm对ClassBForm中的事件进行了监听。
所以根据我的理解,ClassAForm将得到一个专门为其保留生命周期的长寿命dbContext对象;而ClassBForm将得到自己的dbContext对象。因此,如果我在ClassBForm的dbContext中更改了ClassB对象,那么,在ClassAForm的dbContext版本中查看ClassB对象的更改的理想方法是什么?其中,ClassB很可能是ClassA的导航属性。 我可以想到几种解决这个问题的方法,但我不确定哪种是最佳实践;同时也可能(我希望有人能提到)我的整个理解或框架是错误的。
我想到的一些(可能的)解决方案如下:
假设我有ClassA和ClassB两个类,所有ClassA对象都有一个可选的ClassB对象(以及EF6用作外键的相关“ClassBId”属性)。我们有一个名为ClassAForm的窗体,供用户编辑和查看ClassA对象,并且自然地显示一些有关其ClassB对象的信息;这个ClassB应该是ClassA专属的,但也可能在其他表单上查看。这个表单上有一个按钮,打开另一个名为ClassBForm的表单,允许用户编辑和查看ClassB对象。ClassBForm不是模态的,当前也没有向生成它的ClassAForm传递任何内容,尽管ClassAForm对ClassBForm中的事件进行了监听。
所以根据我的理解,ClassAForm将得到一个专门为其保留生命周期的长寿命dbContext对象;而ClassBForm将得到自己的dbContext对象。因此,如果我在ClassBForm的dbContext中更改了ClassB对象,那么,在ClassAForm的dbContext版本中查看ClassB对象的更改的理想方法是什么?其中,ClassB很可能是ClassA的导航属性。 我可以想到几种解决这个问题的方法,但我不确定哪种是最佳实践;同时也可能(我希望有人能提到)我的整个理解或框架是错误的。
我想到的一些(可能的)解决方案如下:
- 忽略Microsoft的建议,仅为特定的DB交互保持dbContext活动状态;在每次更新事件和表单加载时刷新dbContext(像Web应用程序一样)
- 从一个窗体传递相同的dbContext(在我的情况下,在存储库类的构造函数中),并且只在必要时进行处理(不是理想的做法-数据库由一些服务更新)
- 手动附加/分离并将更新标记为已更新
- 通过事件向其他窗体传递更新的对象,并在每个上下文中手动更新对象(我认为当需要保存更改时会遇到麻烦?)