This project is read-only.

EFDAL: Immutable Table and EntitiesClass

Feb 16, 2011 at 8:17 PM
Edited Feb 16, 2011 at 8:18 PM

When I set a table to Immutable en IsTypeTable both to true, I am not longer able to use the following statement in mine CollectionClass:

        ///<summary>
        ///</summary>
        ///
        ///<returns></returns>
        public IList<GeslachtPaard> RunSelect()
        {
            return db.GeslachtPaard.ToList();
        }

This is because the table GeslachtPaard is not present in the class xxxEntities.cs. Is this by Design or is it a bug ? When it is by design, what would be the proper way to make a method that returns all the entries of the table geslachtPaard (thus will be used by the dropdown ?

Feb 20, 2011 at 3:51 PM

This is true. Entity Framework has no real concept of read-only properties. A type table is really nothing more than an ID and a name. As such we generate an enumeration for this. The enum provides a list of possible values and the numeric value is the ID. Do you need this information so you can populate combos and set foreign keys in code? If so you can simple use the enumeration. That said, do you think you still need an actual entity to be generated? We have debated doing this but there is no great way of representing immutable type table in EF. Let me know your thoughts.

Feb 22, 2011 at 10:35 PM

Thank you for your reply. Mine domain/lookup tables have most of the time 3 columns: ID, Description, ShortDescription. The last column I use for grids with (too) large information, with enums it aint easy to use the third column in i.e. grids.
IMHO it would be a good idea to add the table (or when you have checked an option) to the Entities-class. It is the developers responsibility, that the developer doesnt make code, that is able to edit een typable table.