到目前为止,我提出的解决方案是使用“部分”类,后面会称赞它们,第二个是编写一个全新的dbcontext,包括第一个以某种方式或扩展它,但这意味着额外的每个模块的db连接(每个db上下文).有关于此的任何想法？什么是最佳做法？此外,我需要能够使用迁移.
更明确地说,可能的情况如下：
A)您创建一个.dll,其中包含一些dbContextBase类和表(类).
B)您以自己的方式创建依赖/扩展dbContextBase的其他.dll *
C)您在项目中引用.dll并将其扩展.
所以基本上你可以有一个核心dbContext,然后添加一个菜单模块,然后你添加一个博客模块(但它可以通过菜单模块看到,以创建最新的博客文章菜单等).最重要的是,如果您想要一个特定的博客一次性功能,您可以快速集成它,但也可以保持您的博客模块可更新.
解决方法
一旦有了映射类,就可以使用一些模块接口为每个模块收集所有模块接口,或者使用反射来浏览程序集并创建映射类的实例.这些类可以直接由DbModelBuilder使用(在OnModelCreating中或直接使用).
Also I need to be able to work with migrations.
我不确定迁移是否已准备就绪,因为它有一些先决条件：
>所有共享表必须由核心程序集处理 – 它自己的DbMigration派生类(或新版本的类)
>每个模块必须处理自己的表 – 它自己的DbMigration派生类(或新版本的类)
>模块不得更改共享表
>模块不得更改或访问其他模块的表
这意味着您为核心设置了特殊迁移集,并为每个模块设置了一个迁移集.每个迁移集都在单独的程序集中定义 – 这可能是潜在的问题.我自己没有尝试过,所以我不知道EF迁移是否可以解决这个问题 – 我特别针对您真正需要模块化系统的场景,其中模块可以随着时间的推移添加或删除,因此您需要安装(Up方法)和卸载(向下方法).
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
