Метод Add(), добавляющий повторяющиеся строки для связанных моделей в Code-First Entity Framework

Следующий код кажется немного странным:

var loanViewModel = loanEditorViewModel.LoanViewModel;

loanViewModel.LoanProduct = LoanProductService.GetLoanProductById(loanViewModel.LoanProductId); // <-- don't want to add to this table in database
loanViewModel.Borrower = BorrowerService.GetBorrowerById(loanViewModel.BorrowerId); //<-- don't want to add to this table in database

Models.Loans.Loan loan = AutoMapper.Mapper.Map<Models.Loans.Loan>(loanEditorViewModel.LoanViewModel);

Вы устанавливаете ссылки на объекты в модели представления, а затем вызываете automapper. ViewModels не должны содержать ссылки на объекты, а automapper должен эффективно игнорировать любые объекты, на которые есть ссылки, и отображать только создаваемую структуру объектов. Automapper будет создавать новые экземпляры на основе передаваемых данных.

Вместо этого что-то вроде этого должно работать так, как ожидалось:

// Assuming these will throw if not found? Otherwise assert that these were returned.
var loanProduct = LoanProductService.GetLoanProductById(loanViewModel.LoanProductId);
var borrower = BorrowerService.GetBorrowerById(loanViewModel.BorrowerId);

Models.Loans.Loan loan = AutoMapper.Mapper.Map<Models.Loans.Loan>(loanEditorViewModel.LoanViewModel);
loan.LoanProduct = loanProduct;
loan.Borrower = borrower;

Редактировать:

Следующее, что нужно проверить, это то, что ваши службы используют ту же самую ссылку DbContext. Используете ли вы внедрение зависимостей с контейнером IoC, таким как Autofac или Unity? Если это так, убедитесь, что DbContext зарегистрирован как экземпляр на запрос или аналогичная область времени существования. Если Службы эффективно обновляют новый DbContext, то LoanService DbContext не будет знать об экземплярах Продукта и Заемщика, которые были получены DbContext другой службы.

Если вы не используете библиотеку DI, вам следует подумать о ее добавлении. В противном случае вам потребуется обновить свои службы, чтобы они принимали один DbContext при каждом вызове, или использовать шаблон единицы работы, такой как DbContextScope Mehdime, чтобы облегчить службам разрешение своего DbContext из единицы работы.

Например, чтобы обеспечить тот же DbContext:

using (var context = new MyDbContext())
{
    var loanProduct = LoanProductService.GetLoanProductById(context, loanViewModel.LoanProductId);
    var borrower = BorrowerService.GetBorrowerById(context, loanViewModel.BorrowerId);

    Models.Loans.Loan loan = AutoMapper.Mapper.Map<Models.Loans.Loan>(loanEditorViewModel.LoanViewModel);
    loan.LoanProduct = loanProduct;
    loan.Borrower = borrower;

    LoanService.AddNewLoan(context, loan);
}    

Если вы уверены, что все службы предоставляются одним и тем же экземпляром DbContext, то в вашем методе Entities.Add() может происходить что-то странное. Честно говоря, в вашем решении слишком много абстракции вокруг чего-то такого простого, как операция создания и ассоциации CRUD. Это похоже на случай преждевременной оптимизации кода для DRY, не начав с самого простого решения. Код может проще просто ограничить DbContext, выбрать применимые объекты, создать новый экземпляр, связать, добавить в DbSet и сохранить изменения. Нет никакой пользы в абстрагировании вызовов для элементарных операций, таких как выборка ссылки по идентификатору.

public ActionResult Add(Models.ViewModels.Loans.LoanEditorViewModel loanEditorViewModel)
{
    if (!ModelState.IsValid)
        return View(loanEditorViewModel);

    var loanViewModel = loanEditorViewModel.LoanViewModel;
    using (var context = new AppContext())
    {
       var loanProduct = context.LoanProducts.Single(x => x.LoanProductId == 
loanViewModel.LoanProductId);
       var borrower = context.Borrowers.Single(x => x.BorrowerId == loanViewModel.BorrowerId);
       var loan = AutoMapper.Mapper.Map<Loan>(loanEditorViewModel.LoanViewModel);
       loan.LoanProduct = loanProduct;
       loan.Borrower = borrower;
       context.SaveChanges();
    }
    return RedirectToAction("Index");
}

Посыпьте некоторой обработкой исключений, и все готово. Никаких многоуровневых сервисных абстракций. Оттуда вы можете стремиться сделать действие пригодным для тестирования, используя контейнер IoC, такой как Autofac, для управления контекстом и/или вводя шаблон репозитория/сервисного уровня /w UoW. Вышеизложенное будет служить минимально жизнеспособным решением для действия. Любая абстракция и т. д. должна применяться впоследствии. Сделайте набросок карандашом, прежде чем наносить масло. :)

Используя DbContextScope Mehdime, это будет выглядеть так:

public ActionResult Add(Models.ViewModels.Loans.LoanEditorViewModel loanEditorViewModel)
{
    if (!ModelState.IsValid)
        return View(loanEditorViewModel);

    var loanViewModel = loanEditorViewModel.LoanViewModel;
    using (var contextScope = ContextScopeFactory.Create())
    {
       var loanProduct = LoanRepository.GetLoanProductById( loanViewModel.LoanProductId).Single();
       var borrower = LoanRepository.GetBorrowerById(loanViewModel.BorrowerId);
       var loan = LoanRepository.CreateLoan(loanViewModel, loanProduct, borrower).Single();
       contextScope.SaveChanges();
    }
    return RedirectToAction("Index");
}

В моем случае я использую шаблон репозитория, который использует DbContextScopeLocator для разрешения ContextScope для получения DbContext. Репозиторий управляет получением данных и гарантирует, что при создании объектов будут предоставлены все необходимые данные, необходимые для создания полного и действительного объекта. Я выбираю репозиторий для каждого контроллера, а не что-то вроде общего шаблона или репозитория/сервиса для каждого объекта, потому что IMO это лучше управляет принципом единой ответственности, учитывая, что код имеет только одну причину для изменения (он обслуживает контроллер, а не разделяется между многими контроллеры с потенциально разными проблемами). Модульные тесты могут имитировать репозиторий для обслуживания ожидаемого состояния данных. Методы получения репо возвращают IQueryable, чтобы логика потребителя могла определить, как она хочет использовать данные.

Проверьте Models.Loans.Loan? Это объединенная модель таблицы Loans, LoanProduct и Borrower.

Вы должны добавить

Loans  lentity = new Loans()
lentity.property=value;
Entities.Add(lentity );

var lentity = new Loans  { FirstName = "William", LastName = "Shakespeare" };
context.Add<Loans  >(lentity );
context.SaveChanges();

Наконец, с помощью ссылки, которой поделился @GertArnold Дубликат DataType создается при каждом создании продукта..

Поскольку все мои модели наследуют класс BaseModel, я изменил свой метод Insert следующим образом:

public virtual void Insert(TEntity entity, params BaseModel[] unchangedModels)
{
    if (entity == null)
        throw new ArgumentNullException(nameof(entity));

    try
    {
        entity.DateCreated = entity.DateUpdated = DateTime.Now;
        entity.CreatedBy = entity.UpdatedBy = GetCurrentUser();

        Entities.Add(entity);

        if (unchangedModels != null)
        {
            foreach (var model in unchangedModels)
            {
                _context.Entry(model).State = EntityState.Unchanged;
            }
        }

        _context.SaveChanges();
    }
    catch (DbUpdateException exception)
    {
        throw new Exception(GetFullErrorTextAndRollbackEntityChanges(exception), exception);
    }
}

И назвал это так:

_LoanService.Insert(loan, loan.LoanProduct, loan.Borrower);

Безусловно, самый простой способ решить эту проблему — добавить два примитивных свойства внешнего ключа в класс Loan, то есть LoanProductId и BorrowerId. Например, вот так (я, очевидно, должен угадать типы LoanProduct и Borrower):

public int LoanProductId { get; set; }
[ForeignKey("LoanProductId")]
public Product LoanProduct { get; set; }

public int BorrowerId { get; set; }
[ForeignKey("BorrowerId")]
public User Borrower { get; set; }

Без примитивных свойств FK у вас есть так называемый независимые ассоциации, который можно установить только путем назначения объектов, состояние которых должно тщательно управляться. Добавление свойств FK превращает его в ассоциации внешних ключей, который легче установить. AutoMapper просто установит эти свойства, когда имена совпадут, и все готово.