locked
Should I create one or more E-F diagrams for a mult-function MVC app that uses one Database RRS feed

  • Question

  • User-734459410 posted

    Should I create one E-F model/diagram in VS for my MVC app that has different functions (ie. areas) but uses one database, or should I just create one single E-F diagram and just reference that across the entire MVC application?

    (I'm creating an N-tier layout with a DomainModel and DataAccess Layer if that matters.)  The MVC app has three major Areas: Customers, Production and Inventory, but right now I have all the data stored in a single database for easier management of user logins, etc (I am using Asp.Net identity 2.0, but I don't think that matters for my question).

    Wednesday, November 8, 2017 10:49 PM

Answers

  • User1120430333 posted

    Code First can only be executed by one DbContext

    That's more like one DBContext per database,  and one cannot query across DBContext. It doesn't matter if it is Code, Model or Database first.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, November 9, 2017 2:49 PM

All replies

  • User1120430333 posted

    Myself, the Repository pattern would come into play here, which derived from Domain Driven Design.  RepoCustomer, RepoProduction and RepoInventory, and of course, each one responsible for its area. They most likely would not be generic repositories for data persistence, because a RepoCustomer may need to call on RepoInventory's functionality.

    Each repository of course would be able to call objects on the DAL for CRUD operations with the single database. If EF is being used, then the entities should be left at the DAL and DTO(s) sent through the tiers.

    http://deviq.com/repository-pattern/

    http://blog.sapiensworks.com/post/2012/11/01/Repository-vs-DAO.aspx

    Wednesday, November 8, 2017 11:46 PM
  • User-707554951 posted

    Hi cbassett,

    It may seem that multiple contexts provide better data isolation, clearer and subdivided access, but -

    Generally do not need this design. One contexts(E-F diagrams)  should be better

    The reason is simple summed up two:

    Code First can only be executed by one DbContext

    Exchange data between different DbContext is a waste of resources.

    Related link:

    https://stackoverflow.com/questions/11197754/entity-framework-one-database-multiple-dbcontexts-is-this-a-bad-idea

    Best regards

    Cathy

    Thursday, November 9, 2017 7:52 AM
  • User1120430333 posted

    Code First can only be executed by one DbContext

    That's more like one DBContext per database,  and one cannot query across DBContext. It doesn't matter if it is Code, Model or Database first.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Thursday, November 9, 2017 2:49 PM
  • User-734459410 posted

    That's sort of what I figured.  I mean, I'm doing database first (not code first) and that I only needed one DbContext for the entire DB.  I was looking through the repository pattern, and I can use that in the design (as suggested above by someone else), but I was more concerned about having different diagrams/mappings/contexts to different tables based more on what section of the app needed to use what tables, but it sounds like one DbContext and then just extract what I need is sufficient for my needs

    Thursday, November 9, 2017 3:33 PM
  • User1120430333 posted

    but I was more concerned about having different diagrams/mappings/contexts to different tables based more on what section of the app needed to use what tables,

    But you see that's the beauty of using the Repository, Data Access Object, and Data Transfer Object patterns  in combination with each other with DAO  doing all CRUD on a per table/entity basis that allows one to call over to other DAO(s) and return child DTO(s) to a parent DTO or any combination of DTO(s) one see fit to return to the client.

    The client just happens to be a MVC client.

    http://blog.sapiensworks.com/post/2012/11/01/Repository-vs-DAO.aspx

    RepoStudent call DAOStudent, but DAOStudent made calls to DAOEnrollment and DAOCourse to get data tahe the MVC solution needed when working with a Student functionality, which was returned by usage of the DTO(s). 

    The  GetStudentById() shows the functionality.

    using System;
    using System.Collections.Generic;
    using Entities;
    
    namespace DAL.DAO
    {
        public interface IDAOStudent
        {
            DTOStudent GetStudentById(Int32 id);
            List<DTOStudent> GetStudents();
            void CreateStudent(DTOStudent dto);
            void UpdateStudent(DTOStudent dto);
            void DeleteStudent(Int32 id);
        }
    }
    
    using System;
    using System.Collections.Generic;
    using System.Linq;
    using System.Data.Entity;
    using System.Data.Entity.Core.EntityClient;
    using System.Data.Entity.Infrastructure;
    using System.Data.SqlClient;
    using Entities;
    using DAL.Model;
    
    namespace DAL.DAO
    {
        public class DAOStudent : IDAOStudent
        {
            public DTOStudent GetStudentById(Int32 id)
            {
                var dto = new DTOStudent();
                using (var context = new CUDataEntities())
                {
                    var student = (context.Students.Where(a => a.StudentID == id)).SingleOrDefault();
    
                    if (student != null)
                    {
                        dto.StudentID = student.StudentID;
                        dto.FirstName = student.FirstName;
                        dto.LastName = student.LastName;
                        dto.EnrollmentDate = student.EnrollmentDate;
    
                        var enrolllments =  new DAOEnrollment().GetEntrollmentsByStudentId(id).ToList();
                        var courses = new DAOCourse().GetCoursesByStudentCourseId(student.StudentID).ToList();
    
                        dto.EnrollsandCourses = (from a in enrolllments
                                      join b in courses on a.CourseID equals b.CourseID
                        select new  DTOEnrollandCourse()
                         { Title = b.Title, Credits = b.Credits, Grade = a.Grade }).ToList();
                    }
                }
    
                return dto;
            }
    public void CreateStudent(DTOStudent dto) { using (var context = new CUDataEntities()) { var student = new Student { FirstName = dto.FirstName, LastName = dto.LastName, EnrollmentDate = dto.EnrollmentDate }; context.Students.Add(student); context.SaveChanges(); } } public void DeleteStudent(int id) { Student student; using (var context = new CUDataEntities()) { student = (context.Students.Where(a => a.StudentID == id)).SingleOrDefault(); } using (var newContext = new CUDataEntities()) { newContext.Entry(student).State = System.Data.Entity.EntityState.Deleted; newContext.SaveChanges(); } } public List<DTOStudent> GetStudents() { var dtos = new List<DTOStudent>(); using (var context = new CUDataEntities()) { var adapter = (IObjectContextAdapter)context; var objectContext = adapter.ObjectContext; var entityConn = objectContext.Connection as EntityConnection; var dbConn = entityConn.StoreConnection as SqlConnection; dbConn.Open(); var students = context.Students.ToList(); foreach(var stud in students) { var dto = new DTOStudent { StudentID = stud.StudentID, FirstName = stud.FirstName, LastName = stud.LastName, EnrollmentDate = stud.EnrollmentDate }; dtos.Add(dto); } } return dtos; } public void UpdateStudent(DTOStudent dto) { var student = new Student(); using (var context = new CUDataEntities()) { student = (context.Students.Where(a => a.StudentID == dto.StudentID)).SingleOrDefault(); } if (student != null) { student.FirstName = dto.FirstName; student.LastName = dto.LastName; student.EnrollmentDate = dto.EnrollmentDate; } using (var dbcontext = new CUDataEntities()) { if (student != null) { dbcontext.Entry(student).State = EntityState.Modified; dbcontext.SaveChanges(); } } } } }

    Thursday, November 9, 2017 9:16 PM