CODEWITHSUNDEEP
c#asp.netasp.net-mvcasp.net-mvc-4
user3142564
user3142564

Reputation: 33

Database First and Areas

I am currently dealing with a database of more than 30 tables, with some like User, Student, Teacher, School, Enrollment, Courses, Calendar, Activities, CollegeTeams, MusicBand etc etc. I would like to work with Areas in order to better organize the application, but my question is: Should I keep the Entities on the corresponding Area models or in the Main Application Model folder? If distributing the Entities in the corresponding Area Model folder, how would I be able to pass the data to the views if using ViewModel approach? E.G. if creating a signup view inside the Student Area for Students interested in the College Music Band?

Upvotes: 3

Views: 122

Answers (4)

Hamdi Baligh
Hamdi Baligh

Reputation: 892

One of the best practises is to externilize all your domain model into a hole different project (a new C# class library). In order to enhance your code maintenance, you can also create another class library in your solution wich would be your Data Access Layer. The DAL project will reference the Domain Model project in order to realize the data access operation against every class of your Model (these operations are basicly the CRUD operations : Create Read Update and Delete). The DAL project can be split into repositories (a repository for every class in your domain model : http://msdn.microsoft.com/en-us/library/ff649690.aspx )If your requirements go further than CRUD operations against your domain model, you can create an other layer in your application : Say hello to the Service layer :D So basicly the Service Layer is a transcription of the client requirements. A service can use a the repositories (wich are defined in the DAL project) in order to realize the defined requirements. Once the Service layer is implemented, you can call it from your controller wich goes into your Web Project (or you can reference the DAL Project if you didn"t chose to add a Service Layer in your application architecture). So, using this approach, you will be using a clean and a much better architecture of your application. Don't forget to include the references to every project if you want to use it. Hope this helps.

Upvotes: 1

Dipal Mehta
Dipal Mehta

Reputation: 462

It will be good if you can arrange your entities with context(Module) wise folder in different Class library project such as "YourDomain.Models" not in Areas.

And introduce something like DTO that will glue your Web and actual Models to achieve loose coupled architecture.

Hope helps.

Upvotes: 0

Aaron Palmer
Aaron Palmer

Reputation: 8992

In an application of any complexity I typically have at least 3 projects in my solution. One for Data where I put my EDMXs, one for the Web where the Areas are defined with their associated Views, Controllers and ViewModels, and a Common project where the EDMX models (POCOs) are located.

It seems as if you are crossing definitions of Entity models and View models. These should be two completely separate concepts in your application. The EDMX defines the mapping from the DB to the Entity models. In the Web app, there should be some mechanism for mapping Entity models to/from View models. This ViewModel mapping should be done in the specific Area that they are used.

I don't know if this is exactly what you are looking for, but I hope it is helpful.

Upvotes: 1

Wiktor Zychla
Wiktor Zychla

Reputation: 48250

Distributing classes between folders doesn't make them inaccessible from classes in other folders.

It is the contrary, you could even have a complete separate folder or even a separate project for your model classes or domain entities and still be able to use them anywhere in the same project or any project that references the project containing your classes.

Upvotes: 1

Related Questions