Where to put Entity Framework Data Model in MVC application? Specific example

Question

First I want to refer to this post:

Where to put Entity Framework Data Model in MVC application?

My edmx will have 7-10 tables in it. Not more.

The problem is I have to build my model which I´m working with out of [lets say] 4 tables. So I´m asking myself: Are these tables real model representations and would it be correct to put the edmx file in the "Models" folder and how should I name this CONTAINER of models?

Or are 10 tables enough to create a new project? How to call the project? .DataAccess? How to name the edmx file in it?

I don´t have that much experience with MVC and EF and am trying to figure out a best practice there.

Update: This post tells me not to put it in the Models folder: "The model should be decoupled from the backend data store technology as much as possible."

Answer 1

My response is based on Silverlight and I understand it's a bit out of context because you are asking from MVC view point. But please allow me to illustrate where I put my EDMX

First project solution

-Widgets. These are multiple UI projects with multiple XAML pages

-UI logic is heavy orchestrating every widget and XAML pages in one main user interface

-View-Models. These are almost equivalent to controllers in MVC. I use XAML to directly bind to View-Models. Example QuotationItemModel.vb and xyz.vb and such. Multiple XAML pages may share 1 VM.

-XAML pages suppose to use command bindings as per implementating View-Models. Example button click is routed to VM. I didn't achieve this because the UI coordination logic (from another UI architect) was interfering with my hooking to delegate command (of CanExecute, Execute Func(Of Object, Boolean) Action(Of Object) causing a stack overflow in first level widgets' click event.)

-Model. There is but one function here. Her job hooks a delegate to web service async call completed event and then triggers the webservice. Deletegate's implementation actually sits back into in View-Model i.e. QuotationItemModel.vb and not inside Model. There is truly only one function in Model.vb

-There is no other logic in Model. i.e. Model.vb decides end points, http bindings, WCF stuffs

-There is no EDMX whatsoever in this solution. Model also knows nothing about database.

Second project (but inside third solution)

• WCF implementation. Light weight. Again 1 function. Operation contracts only.

• Code behind only pass business objects into third project.

• Connection string for EDMX is configured here and passed to third project.

• No other logic.

• There is no awareness of EDMX whatsoever

Third project solution

-Begins with a simple factory to delegate logic and invoke classes

-Begins with simple factory logic becomes very heavy backend. Uses design patterns to alleviate maintenance concerns. From here, the patterns could criss cross between commands, strategy, or abstract types etc etc.

-The EDMX design is fully apparent in this layer

-Business objects interacts in logical manner with EDMX

-I either do LINQ to Entities or parameterized queries here

-This layer consist of business logic such as Underwriting ID must exist before a claim transaction can be issued. Or a quotation's running number sequence based on server date. etc etc

-There are some manual mapping of business objects to Entities. Potentially tedious but not always

-Result is passed back as XML

The third project could very well be separated solution with another lightweight webservice in between, producing readiness for 3 tier architecture. Then I will produce my own connection string to EDMX at this pure layer. But mine is now more like '2.5' layer 2 architecture. I sheepishly expose the connection string in middle tier's web config. Architecture means having another hardware platform altogether. Layer are separation for domain driven design in problem space i.e. UI, communication and business domains. Technically speaking the database of SQL Server (beyond the EDMX) could very well sit in another architecture i.e. Windows Azure

There are pros and cons I see here. Please bring any criticisms gently, I am new to layering, really.

Cons Without exposing data contracts my UI is blind when communicating in language of business objects and contracts. Previously this was easily achieved by having the EDMX in WCF layer. I now used Xelement to represent shared business object. But I still need to figure a way to expose the data contract without exposing database internals. Currently, I 'instinctively' know and code the database fields in my Xelements.

Potentially it's like silent binding to backend EDMX. Silence is sometimes bad because if I get a column without data there are many suspected causes. Nothing that cannot be solved via good error messaging from the XML result passed-back. Using my imagination.

Weak mechanism for versioning. Perhaps new clients interacts with separate operation contract for a silent redirection to Backend-Ver 2.0 whilst the existing clients utilize Backend-Ver 1.0. This potentially mean you should now have 2 EDMX for each old and new database respectively

Pros Extreme decoupling. I can delete/rebuild the EDMX and UI and WCF still compiles. Only my third solution will get compilation error in this extreme test effort.

From silverlight UI, triggering and communication to Microsoft Report Viewer report shares exactly same classes invoked from UI. There are no 'additional webservice function for report' whatsoever. Whatever EDMX + logic requested by UI exactly same for the report-- unless I chose it not. PS: Silverlight communicates filter criteria to the report via query string.

The report again, is not aware of the EDMX. Example, if I delete the EDMX from backend and then update the data connection from report project and the report project still compiles without problems.

Readiness for migration to multiple architecture without tears. Seasonal load balancing, increase in customer base etc may trigger this investment in architecture.

Reusability of business logic. For example, if the boss gets tired of Silverlight, I just need to re-code the UI business objects, say, into JSON?? under HTML 5. There are no changes to business logic whatsoever, except new requirements. Example, to expand into Life Insurance to co-exist with existing General insurance, a module which is currently coded in Silverlight. Imagine Life Insurance in HTML 5 and still coexisting with same backend. Again, the reason is because both front end is not aware of EDMX I just need to focus on building data contract from within new technology.

Unexpected (I am new to layering really!) side effect. I potentially can test my backend separate from UI. Which in turn manipulate LINQ to Entity (that EDMX). Cool for unit testing.

Updating business logic does not effect new deployment to IIS (Middle layer) except maybe when it comes to versioning.

Anyway here's Layered Application Solution Guidance from talented software architect Serena Yeoh

Layered Architecture Sample for .NET

http://layersample.codeplex.com/

http://layerguidance.codeplex.com/

Notice in the sample which you download, the ingenuity of having multiple UI over different technologies over a common backend, where the EDMX live and sleep. And what's more, over windows workflow foundation, selectively called as needed. You can see where Serena put the EDMX and you have at it with workable running code. Pure bliss.

Answer 2

Personally my MVC projects (regardless of size) consist of the following as a minimum:

• Data
• Logic
• Site

This structure seems to work pretty well as it separates business logic from storage and display.

You definitally don't want to put the EDMX in the models folder as that is reserved for view models. Best practice says that view models should be entirely disconnected from your storage entities.

In terms of naming the EDMX i normally name it after the short name of the project, the more important thing is to get the namespace right for the EDMX so your models sit in the correct namespace location.