.NET Entity framework project layout (architecture)

Question

I'm trying to determine how best to architect a .NET Entity Framework project to achieve a nice layered approach. So far I've tried it out in a browse-based game where the players own and operate planets. Here's how I've got it:

Web Site

This contains all the front end.

C# Project - MLS.Game.Data

This contains the EDMX file with all my data mappings. Not much else here.

C# Project - MLS.Game.Business

This contains various classes that I call 'Managers' such as PlanetManager.cs. The planet manager has various static methods that are used to interact with the planet, such as getPlanet(int planetID) which would return an generated code object from MLS.Game.Data.

From the website, I'll do something like this:

var planet = PlanetManager.getPlanet(1);

It returns a Planet object from from the MLS.Game.Data (generated from the EDMX). It works, but it bothers me to a degree because it means that my front end has to reference MLS.Game.Data. I've always felt that the GUI should only need to reference the Business project though.

In addition, I've found that my Manager classes tend to get very heavy. I'll end up with dozens of static methods in them.

So... my question is - how does everyone else lay out their ASP EF projects?

EDIT

After some more though, there's additional items which bother me. For example, let's say I have my Planet object, which again is generated code from the wizard. What if a time came that my Planet needed to have a specialized property, say "Population" which is a calculation of some sort based on other properties of the Planet object. Would I want to create a new class that inherits from Planet and then return that instead? (hmm, I wonder if those classes are sealed by the EF?)

Thanks

Answer 1

You could try the following to improve things:

• Use EF to fetch DTOs in your Data layer, then use these DTOs to populate richer business objects in your Business layer. Your UI would only then need to reference the Business layer.
• Once you have created the rich business objects, you can begin to internalise some of the logic from the manager classes, effectively cleaning up the business layer.

I personally prefer the richer model over the manager model because, as you say, you end up with a load of static methods, which you inevitibly end up chaining together inside other static methods. I find this both too messy and, more importantly, harder to understand and guarantee the consistency of your objects at any given point in time.

If you encapsulate the logic within the class itself you can be more certain of the state of your object regardless of the nature of the external caller.

A good question by the way.