title: Entity Framework, Existing Database, Code First - Ignoring Db Columns and Changing Datatypes
body: <p>I'm using Entity Framework 4.3 (I'm open to suggestions on changing this if EF can't do what I need).</p>
  
  <p>I have some Entities/Business Objects.  These objects should not change, should not be annotated (no DataAnnotation Attributes), should not have internal members added for workarounds, and the database is also set in stone / beyond my control.  In short, the DB cannot change, nor can my entities.  That, at first, sounded like a perfect reason to use Fluent API.</p>
  
  <pre><code>public class MyEntity
  {
      public int MyEntityId { get; set; }
      public string Name { get; set; }
      public bool IsGreen { get; set; }
  }
  </code></pre>
  
  <p>Let's say the table to which this object relates in the database is as follows:</p>
  
  <pre><code>CREATE TABLE [dbo].[MyEntities]
  (
  MyEntityId INT NOT NULL,
  Name VARCHAR(30) NOT NULL,
  IsGreen CHAR(1) NOT NULL,
  ForeignKeyId INT NULL
  )
  </code></pre>
  
  <p><em>apologies if the SQL is wrong, quickly hand typed</em></p>
  
  <p>Hopefully you'll notice straight away a couple of conflicts.</p>
  
  <p>Question 1)  Is it possible, through <strong>Fluent API</strong>, to map my boolean to the <em>IsGreen CHAR(1) NOT NULL</em> field without adding a <em>workaround</em> property to the original entity?  This column is not nullable, the expression to populate the bool would likely be along the lines of:</p>
  
  <pre><code>x =&gt; new MyEntity() { IsGreen = x.IsGreen == "Y" }
  </code></pre>
  
  <p>Question 2) Will the context allow me to Insert MyEntity to the database, despite not all columns being mapped, so long as the columns not mapped are nullable, and even if there is a foreign key?</p>
  
  <p>Question 3) If EF cannot do the above, is there a framework that can?  </p>
  
  <h2>Here's what I've tried so far:</h2>
  
  <p><strong>Attempt 1</strong>:
  I started going down the road of creating seperate <em>entities</em> based on the DB Schema, then creating lengthy expressions to be able to convert from one to the other.  </p>
  
  <p>This may have eventually worked, but ignoring the ludicrous amount of time it was taking, it created a new issue; my <code>Expression&lt;Func&lt;MyEntity, bool&gt;&gt;</code> expressions for where clauses could obviously no longer be applied at the DB, instead having to bring all records back, compiling the expression, and applying it to a resulting enumerable.  </p>
  
  <p>This is not good enough unfortunately, there is simply too much data being brought back.  I could have spent some time writing code that walked through the expressions and mapped the <code>MemberAccess</code> nodes to the new entity, but that seemed unnecessarily complex.</p>
  
  <hr>
  
  <p><strong>Attempt 2</strong>:</p>
  
  <p>I then tried to create inherited classes, which <em>could</em> contain <em>workaround</em> properties, setting the actual properties in their setters, whilst the actual properties were ignored through the fluent API.  Thanks to the inheritance, my aforementioned where expressions should then have worked.</p>
  
  <p>However, the inheritance was discovered by EF, and I was no longer able to query the database due to the schema not matching the inheritance hierarchy of entities it seemed to be expecting.  (I appreciate that's a little vague, but consider the TPH/TPT/etc aspects of EF, and how that wasn't necessarily matching my schema - I think this was my closest attempt but I didn't know how to correct the issues through the fluent API).</p>
  
  <hr>
  
  <p><strong>Attempt 3</strong>:
  Finally, I tried to tinker with the designer.  Not much to say about that one, except that I'm no longer tinkering with the designer.  </p>
  
  <hr>
  
  <p>NB: this software needs to run against several different databases, those databases will not have exactly the same schema each time, which is why for example I need the code to work even though my model doesn't necessarily have a property for each column present in the DB.  Not only that, but I do not know, before the software ships, how many or what extra columns the database may have, all I know is that the columns are nullable, and therefore I should be able to insert into the table knowing only the core non-null columns (which are those present on MyEntity objects).  This alone, I believe, rules out the designer.</p>
  
  <p>Sorry for the wall of text - any help appreciated!</p>