Where to place the Entity Framework data model in an MVC application? Specific example

Question

First I want to refer to this post:

Where to place the Entity Framework data model in an MVC application?

In my edmx there will be 7-10 tables. Not more.

The problem is that I need to build my model, with which I work from [say] 4 tables. Therefore, I ask myself: are these tables real representations of the model, and would it be correct to place the edmx file in the Models folder, and what should I name this CONTAINER of models?

Or is it enough 10 tables to create a new project? How to call the project?. Access to data? How to name the edmx file in it?

I don't have much experience with MVC and EF, and I'm trying to find the best practice there.

Update : In this message, I do not need to put it in the Models folder: "The model should be separated from the technology backend data store as much as possible."

Answer 1

Personally, my MVC projects (regardless of size) consist of at least:

• Data
• brain teaser
• Website

This structure works very well because it separates business logic from storage and display.

You definitely do not want to put EDMX in the models folder, as it is reserved for view models. Best practice says view models should be completely disconnected from your storage objects.

In terms of the EDMX name, I usually name it after the project’s short name, the more important it is to get the namespace for EDMX so that your models sit in the right place in the namespace.

Answer 2

My answer is based on Silverlight, and I understand it a little out of context, because you are asking for the point of view of MVC. But please let me illustrate where I posted my EDMX

First design decision

-Widgets. These are several user interface projects with multiple XAML pages.

-UI-logic - heavy organization of each widget and XAML pages in one main user interface

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

-XAML pages suggest using command bindings in accordance with the View-Models implementation. An example of a button click is redirected to a virtual machine. I did not achieve this because the UI consistency logic (from another UI architect) interfered with my connection for delegating a command (from CanExecute, Execute Func (Of Object, Boolean) An action (from an object) causing a stack overflow in a first-level click event widgets.)

-model. There is only one function here. Her work intercepts the delegate to complete the asynchronous call to the web service, and then starts the web service. The implementation of Deletegate actually returns back to View-Model ie QuotationItemModel.vb, and not inside the model. In Model.vb

there is really only one function.

- There is no other logic in the Model. i.e. Model.vb solves endpoints, http bindings, WCF components.

- There is no EDMX in this solution. The model also knows nothing about the database.

The second draft (but inside the third solution)

• WCF implementation. A light weight. Again 1 function. Operating contracts.

• The code is only for transferring business objects to the third project.

• The connection string for EDMX is configured here and transferred to the third project.

• No other logic.

• There is no awareness of EDMX at all

Third design decision

-Begins with a simple factory for delegating logic and calling classes

- Begins with simple factory logic get very heavy. Uses design patterns to ease maintenance problems. From here templates can cross commands, strategies or abstract types, etc. Etc.

- EDMX design is fully apparent in this layer

-Business objects interact logically using EDMX

-I either LINQ to Entities or parameterized queries here

. This layer consists of business logic, such as an underwriting identifier, that must exist before a claims transaction can be issued. Or a quote sequence of numbers based on server date. etc etc.

-There is a manual mapping of business objects with objects. Potentially tiring, but not always

-Result is passed as XML

The third project can be very well separated by a solution using another lightweight web service between them, providing readiness for a 3-tier architecture. Then I will create my own connection string for EDMX on this blank layer. But mine is now more like 2.5 level architecture. I shyly expose the connection string in a mid-tier web configuration. Architecture means having a different hardware platform as a whole. A layer is a separation for domain-driven design in a problem space, that is, a user interface, communication and business domains. Technically speaking, a SQL Server database (outside of EDMX) could well sit in a different architecture, that is, Windows Azure

There are pros and cons that I see here. Please attach any criticisms gently, I'm new to bundle, really.

Cons Without exposing data contracts, my user interface is blind when communicating in the language of business objects and contracts. Previously, this was easily achieved thanks to EDMX in the WCF layer. Now I used Xelement to represent a common business object. But I still need to understand how to expose the data contract without exposing the internal database. Currently, I “instinctively” know and encode database fields in my Xelements.

Potentially, it is like a quiet binding to the backend EDMX. Silence is sometimes bad, because if I get a column without data, there are many suspicious reasons. Nothing that can be resolved by well reporting error messages from the XML result is returned. Using my imagination.

Weak mechanism for version control. Perhaps new customers are interacting with a separate operating contract to silently redirect to Backend-Ver 2.0, while existing customers are using Backend-Ver 1.0. This potentially means that you should now have 2 EDMX for each old and new database.

Pros Extreme denouement. I can remove / rebuild EDMX and UI, and WCF is still compiling. Only my third solution will get a compilation error in this extreme test.

From the Silverlight user interface, startup, and communication with the Microsoft Report Viewer, the same classes are published as the user interface. There is no additional webservice function for reporting. No matter what EDMX + logic is requested by the user interface in the same way as for the report - if I did not select it. PS: Silverlight passes the filter criteria to the query line report.

Report again, do not know EDMX. For example, if I remove EDMX from the backend and then update the data connection from the report project, and the report project still compiles without problems.

Willingness to migrate to multiple architectures without tears. Seasonal load balancing, increasing customer base, etc. May provoke this investment in architecture.

Repeatability of business logic. For example, if the boss gets tired of Silverlight, I just need to transcode the business objects of the user interface, say, in JSON ?? for HTML 5. There are no changes in business logic, except for new requirements. For example, to expand life insurance to coexist with existing General Insurance, a module that is currently encoded in Silverlight. Imagine life insurance in HTML 5 and still coexists with the same backend. Again, the reason is that both front-end do not know EDMX, I just need to focus on building contract data from the new technology.

An unexpected (I'm new to bundle really!) Side effect. I can potentially test my server separately from the user interface. This, in turn, manipulates LINQ to Entity (this is EDMX). Cool for unit testing.

Updating business logic does not affect a new deployment on IIS (mid-tier), except maybe when it comes to versions.

Anyway, here's a Layered Application Solution Guide from talented software architect Serena Yeo

An example of a layered .NET architecture.

http://layersample.codeplex.com/

http://layerguidance.codeplex.com/

Pay attention to the sample you download, the ingenuity associated with having multiple user interfaces for different technologies compared to the common backend where EDMX lives and sleeps. And what else, above the base of the Windows desktop, is selectively called as needed. You can see where Serena installed EDMX, and you have working code working on it. Bliss.