2016-01-14 2 views
0

Я осмотрел и увидел, что у многих людей была эта проблема. Однако моя не совсем то же самое. В то время как другие проблемы обычно решаются с использованием правильных перегрузок метода ActionLink и фиксируются, убедившись, что тип возвращаемого объекта в методе верен, это не так.Объект, полученный в методе ActionLink всегда null

В этом примере кода переменные все установлены правильно в соответствии со всеми другими источниками, однако объект пользователя, полученный в методе, всегда равен нулю.

Что я сделал:

  • Проверено, если объект поместить на ActionLink есть данные (это делает)
  • Проверено, если тип объекта я получил правильно, вместе с тем, я отправить
  • Пробовал с помощью Ajax ActionLink и метод HttpPost вместо

Вот код первого из внутреннего интерфейса, а затем FRONTEND

public void DeleteUser(User user) 
    { 
     using (EFEntity context = new EFEntity()) 
     { 
      context.User.Attach(user); 
      context.User.Remove(user); 
      context.SaveChanges(); 
      Response.Redirect("~/Home/someView"); 
     } 
    } 

Действие Ссылка Передняя часть:

foreach (User user in Model.userList) 
{ 
    <tr> 
     <td> 
      @{ 
      number = number + 1; 
      } 
      @number 
     </td> 
     <td>@user.Gid</td> 
     <td>@user.Name</td> 
     <td>@user.Email</td> 
     <td>@user.Permissions.Perm</td> 
     <td>@user.LastUpdated</td> 
     <td> 
       @Html.ActionLink("Delete", "DeleteUser", "Service", user, new { @class = "btn btn-danger" }) 
     </td> 
    </tr> 
} 
+1

Вы не должны быть проходящими комплексом в 'ActionLink()'. Если объекты имеют множество свойств, вы можете легко превысить строку запроса и выбросить исключение (и там создается уродливая строка запроса). Вам просто нужно передать свойство «ID» пользователя. –

+1

И вы даже не должны использовать ссылку на действие - ваши модифицирующие данные, поэтому она должна быть POST - в настоящее время она добавляет историю браузеров пользователей и может быть легко перенесена на другую. В лучшем случае это будет означать, что ненужные вызовы базы данных будут удалять то, что в настоящее время не существует, и в худшем случае может вызвать исключение. Настоятельно рекомендую вам следовать обычной практике. –

+0

@StephenMuecke Пожалуйста, подробно расскажите о репозитории и истории браузера, неясно, что вы имеете в виду. Когда вы нажмете эту кнопку, она обновит страницу, поэтому у вас нет возможности дважды удалить одну и ту же вещь. Или я неправильно понял, что вы имеете в виду? – Snoozles

ответ

0

я понял проблему вне его немного странным одной стороны, это не так уж трудно исправить.

Проверяя объект пользователя «ближе и глядя на исходный код в браузере, вы можете увидеть какую-то строку на объекте, в которой есть куча чисел, а также что-то с« динамическим прокси ».

В ходе дальнейших исследований я узнал, почему объект всегда был нулевым, потому что объект генерировался с помощью параметров динамического прокси. Это по какой-то причине было разрешено самим собой каким-то образом, только на этой конкретной модели EF.

Исправление состоит в том, чтобы отключить использование динамических прокси глобально в рамках сущности.

Как это сделать:

Перейти к вашему Model.edmx -> Model.Context.tt -> Model.Context.cs

Ее вы собираетесь добавить строку «Configuration.ProxyCreationEnabled = false; " внутри общедоступного метода, который является вашей моделью сущности.

код перед:

public partial class EFEntity: DbContext 
    { 
     public EFEntity() 
      : base("name=EFEntity") 
     { 
     } 
     ...... 
    } 

Код После:

public partial class EFEntity: DbContext 
     { 
      public EFEntity() 
       : base("name=EFEntity") 
      { 
       Configuration.ProxyCreationEnabled = false; 
      } 
      ...... 
     } 

Это должно создание глобально отключить прокси и исправить эту конкретную проблему.

Надеется, что это поможет кому-то, я изо все силы выяснить, что случилось в течение нескольких дней

+0

_ «Исправление было отключить использование динамических прокси-серверов в глобальном масштабе в сущности» _ - нет, ** правильное ** исправление заключается в использовании моделей viewmodels вместо моделей Entity Framework. Вам также не придется тратить дни на эту проблему, если бы вы посмотрели созданный HTML. :) – CodeCaster

+0

Я не думаю, что его необходимо вернуть viewmodel, когда все, что вы хотите знать, это то, что нужно удалить. Ваш комментарий о том, как долго я занимаюсь, чтобы выяснить проблему, не очень конструктивен, можете удержать его на тему, пожалуйста. Независимо от того, какой код вы считаете лучшим способом делать, это не так важно, поскольку это не проблема. В этом случае даже использование модели представления, вероятно, все равно вызовет те же проблемы, поскольку все пользовательские объекты из EF генерируются динамическими прокси. – Snoozles

+0

Я только что разместил это сообщение, когда у кого-либо еще была эта проблема, потому что я не мог найти никакой помощи в этом при поиске. так что либо он исправляет свою проблему, либо ведет их по правильному пути. – Snoozles

Смежные вопросы