Home/ Questions/Q 7624735
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-31T05:02:38+00:00

I have an existing database, which I have been happily accessing using LINQtoSQL. Armed

  • 0

I have an existing database, which I have been happily accessing using LINQtoSQL. Armed with Sanderson’s MVC3 book I thought I’d have a crack at EF4.3, but am really fighting to get even basic functionality working.

Working with SQL 2008, VS2010, the folder architecture appears to be:

ABC.Domain.Abstract
ABC.Domain.Concrete
ABC.Domain.Concrete.ORM
ABC.Domain.Entities

Per examples, repository interfaces are abstract, actual repositories are concrete. Creating EDMX from the existing database puts that in the ORM folder and the Entities holds the classes I designed as part of the domain. So far so good.

However! I have not once persuaded the deceptively simple EfDbContext : DbContext class, with method to work…

public DbSet<ABC.Domain.Entities.Person> Person { get { return _context.Persons; }}

It complains about missing keys, that Person is not a entity class, that it cannot find the conceptual model, and so on.

  1. Considering I have a basic connectionstring in the web.config, why is not creating a model on the fly to do simple matching?

  2. Should the ORM folder exist, or should it simply be Concrete? (I have a .SQL subfolder for LINQtoSQL concret so it suits me to have .ORM but if it’s a flaw, let’s fix it).

  3. Should I have my homespun entities AND the automatically produced ones or just one set?
    The automatic ones inherit from EntityObject, mine are just POCO or POCO with complexTypes, but do not inherit from anything.

  4. What ties the home designed Domain.Entities.Person type to the Persons property of the Context?
    Sanderson’s book implies that the matching is implicit if properties are identical, which they are, but that does not do it.

  5. The app.config has an EF flavoured connection string in it, the web.config has a normal connection string in it. Which should I be using – assuming web.config at the moment – so do I delete app.config?

Your help is appreciated. Long time spent, no progress for some days now.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What ties the home designed Domain.Entities.Person type to the Persons
    property of the Context?

    You seem to have a misunderstanding here. Your domain entities are the entities for the database. There aren’t two sets. If you actually want to have two sets of object classes (for whatever reason) you must write any mapping between the two manually. EF only knows about the classes which are part of the entity model.

    You should also – if you are using EF 4.3 – apply the DbContext Generator T4 template to the EDMX file. Do not work with EntityObject derived entities! It is not supported with DbContext. The generator will build a set of POCO classes and prepare a derived DbContext. This set of POCO classes are the entities the DbContext will only know about and they should be your only set of domain entities.

    The created DbContext will contain simple DbSet properties with automatic getters and setters…

    public DbSet<Person> People { get; set; }

    …and the Person class will be created as POCO as well.

    • 0