实体框架、现有数据库、代码优先 - 忽略 db 列和更改数据类型

我正在使用实体框架 4.3（如果 EF 无法满足我的需要，我愿意接受有关更改它的建议）。

我有一些实体/业务对象。 这些对象不应该改变，不应该被注释（没有数据注释属性），不应该为解决方法添加内部成员，并且数据库也是一成不变的/超出我的控制范围。 简而言之，数据库不能改变，我的实体也不能改变。 起初，这听起来像是使用Fluent API的完美理由。

public class MyEntity
{
    public int MyEntityId { get; set; }
    public string Name { get; set; }
    public bool IsGreen { get; set; }
}

假设此对象在数据库中关联的表如下所示：

CREATE TABLE [dbo].[MyEntities]
(
MyEntityId INT NOT NULL,
Name VARCHAR(30) NOT NULL,
IsGreen CHAR(1) NOT NULL,
ForeignKeyId INT NULL
)

抱歉，如果SQL错误，快速手动输入

希望你会立即注意到一些冲突。

问题1） 是否有可能通过 Fluent API 将我的布尔值映射到 IsGreen CHAR（1） NOT NULL 字段，而无需向原始实体添加解决方法属性？ 此列不可为空，用于填充布尔值的表达式可能如下所示：

x => new MyEntity() { IsGreen = x.IsGreen == "Y" }

问题2）上下文是否允许我将 MyEntity 插入到数据库，尽管并非所有列都被映射，只要未映射的列可为空，即使存在外键？

问题3）如果 EF 无法执行上述操作，是否有可以执行的框架？

这是我到目前为止尝试过的：

尝试 1：我开始走上基于数据库模式创建单独实体的道路，然后创建冗长的表达式以便能够从一个转换为另一个。

这可能最终奏效了，但忽略了它所花费的荒谬时间，它创造了一个新问题;我Expression<Func<MyEntity, bool>>表达式 where 子句显然不能再应用于数据库，而是必须恢复所有记录，编译表达式，并将其应用于结果可枚举。

不幸的是，这还不够好，带回的数据太多了。 我本可以花一些时间编写代码来遍历表达式并将MemberAccess节点映射到新实体，但这似乎过于复杂。

尝试 2：

然后，我尝试创建继承的类，这些类可能包含解决方法属性，在其 setter 中设置实际属性，而实际属性通过流畅的 API 被忽略。 多亏了继承，我前面提到的表达应该起作用的地方。

但是，EF 发现了继承，由于架构与它似乎预期的实体的继承层次结构不匹配，我无法再查询数据库。 （我很欣赏这有点模糊，但请考虑 EF 的 TPH/TPT/等方面，以及它不一定与我的架构匹配 - 我认为这是我最接近的尝试，但我不知道如何通过流畅的 API 纠正问题）。

尝试 3：最后，我试着修补设计师。 关于这一点没什么好说的，除了我不再修补设计师了。

注意：该软件需要针对几个不同的数据库运行，这些数据库每次都不会有完全相同的模式，这就是为什么例如我需要代码才能工作，即使我的模型不一定具有数据库中存在的每列的属性。 不仅如此，而且我不知道，在软件发布之前，数据库可能有多少或多少额外的列，我只知道这些列是可为空的，因此我应该能够插入到表中，只知道核心非空列（即 MyEntity 对象上存在的列）。 我相信，仅此一点就排除了设计师。

对不起，文字墙 - 任何帮助表示赞赏！