Basic Entity Framework Questions

Question

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.

Answer 1

The solution to why nothing worked code-first...

...turned out to be a reference to System.Data.EntityClient in the connection string, which ought to have read System.Data.SqlClient.

Without this provider entry being correct, it was unable to work code-first.

Finding which connectionString it was using was a case of deliberately mis-spelling a keyword in the connections there were to choose from - they all were named correctly - but were in app.config, and 2 places in the web.config. With a distinct naming error, when the application threw an error trying to create the domain model, it was easy to identify which connection string my derived DbContext class was using. Correcting the ProviderName made all the difference.

Code-first is now working just fine, with seeded values on model changes.

Answer 2

There are many questions here and you won't get an answer, but I'll stick my 5 pence for what it's worth.

Sanderson's MVC3 book

Your problems are not to do with MVC3, they are to do with Entity Framework and data persistence layer.

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

Can you say why this is separated in such a way? I would argue and say that ABC.Domain should contain your POCOs independent of your persistence layer (EF) and your presentation layer (MVC). Your list implies that your domain contains ORM and your data access entities. I'm not arguing here, what I'm trying to say, is that you need to understand what you really need.

At the end of a day, I'm certain that a simple example would suffice with ABC.DataAccess, ABC.Domain and ABC.Site.

Do you understand why repositories are abstract and concrete? If you don't, then leave out interfaces and see whether you can improve it with interfaces later.

Person is not a entity class, that it cannot find the conceptual model, and so on.

Now, there are multiple ways you can get EF to persist data for you. You can use code first, where, as the name implies, you will write code first, and EF will generate database, relations and all the relevant constraints for you.

You can use database first, where EF will generate relevant class and data access related objects from your database. This is less preferable method for me, as it relies heavily upon your database structure.

You can use model first, where you will design your class in EDMX designer and it will then generate relevant SQL for you.

All of these might sound like a bit of black box, but for what you are trying to achieve all of them will work. EDMX is a good way to learn and there are many step by step tutorials on ASP.Net.

but if it's a flaw, let's fix it).

You will have to fix and refactor yourself, there is no other way to improve in my honest opinion. I can give you a different folder/namespace structure, but there will always be a "better" one.

Should I have my homespun entities AND the automatically produced ones or just one set?

Now this depends on the model that you have chosen. Database first, code first, code only and whatever else is there. If you are following domain driven development, then you will have to work with classes, that represent your business logic and that are not tied up to your data persistence layer or presentation layers, therefore POCO is a way forward.

What ties the home designed Domain.Entities.Person type to the Persons

Now this again depends on the model that you are using.

The app.config and web.config

When you are running your web application, the connection string from web application will be used. Please correct me if I'm wrong.

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

General advise, leave MVC alone for the time being. Get it to work in a console application and make sure you feel comfortable with options offered in EF. Good luck :)

Answer 3

Download the entity framework power tools: http://visualstudiogallery.msdn.microsoft.com/72a60b14-1581-4b9b-89f2-846072eff19d

Right click in your project to 'reverse engineer an existing database' it will create the code classes for you. No need to use EDMX ,and this method will create the DbContext derived class for you

Answer 4

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.