Проверка ASP.NET MVC - LINQ to SQL и просмотр моделей - небольшая помощь по правильному потоку - PullRequest
0 голосов
/ 25 ноября 2010

Я пытаюсь понять, как лучше всего выполнить что-то.

Я создаю очень простой форум, использующий ASP.NET MVC и LINQ to SQL. Очень просто означает, что у него нет категорий, и каждое сообщение состоит из темы, композитора и содержимого сообщения. Комментарии могут быть многопоточными, но углубляться только на один уровень (если вы прокомментируете дочернее сообщение, оно будет выглядеть так, как будто вы прокомментировали родительское сообщение этого дочернего элемента).

О, я тоже правильно разбил форум на страницы.

Теперь бит потока ASP.NET MVC, который я пытаюсь понять:

Когда кто-то переходит на Home/Forum/{page}, я создаю модель для представления с 2 объектами - списком всех отображаемых сообщений (в правильном порядке для родителей и детей. Я создаю список на стороне сервера) и forumMessage newMessage объекта, поэтому, если пользователь создает новое сообщение или отвечает на существующее сообщение, я могу легко заполнить объект и отправить его обратно на сервер.

Однако после прочтения лотов статей о проверке, моделях и т. Д. Мне кажется, что было бы лучше использовать разбитые поля сообщений, которые должен заполнять пользователь (т. Е. : String messageComposer; String messageComposer; String messageContents;), поскольку для них будет легче определить правила проверки.

Это по двум причинам:

1) поскольку объект forumMessage создается с использованием LINQ to SQL, определенно сложно определить его правила проверки (да, я знаю, что вы можете использовать классы друзей , но я вроде напуган О_о)

и что, по-видимому, является основной причиной 2) во всех примерах валидации, если данные, которые требовались для валидации, были переданы как объект (т.е. forumMessage), то это был единственный объект в модели. Я не видел ссылок на сценарии, в которых модель состояла из данных, которые также использовались просто для заполнения представлений (в моем случае - сообщений форума для конкретной страницы).


Что подводит меня к этому:

До сих пор всякий раз, когда мне приходилось получать ввод от пользователя, я передавал объекты, которые хотел отобразить или заполнить, как фактические объекты LINQ to SQL.

Я поступил неправильно? Должен ли я передавать LINQ объектам SQL (т.е. классам) для целей отображения, но использовать простые старые поля (строки, целые и т. Д.) Для данных, которые я хочу получить, и создавать фактический LING на стороне сервера объектов SQL, когда получаю все данные обратно на контроллер?

Я здесь на распутье, и буду признателен за помощь от опытных ветеранов: -)

Спасибо!

1 Ответ

1 голос
/ 25 ноября 2010

Я создаю очень простой форум

Поскольку это простой форум, тогда простейший подход будет наилучшим, т. Е. Использование объекта Linq-2-Sql в течение всего процесса (т. Е. От DAL до View)

Что касается использования сочетания объектов / свойств, я бы использовал отдельную ViewModel для агрегирования данных.

, например

// class used for the strongly typed view
public class ForumMessageViewModel
{
   // linq-2-sql class
   public List<Message> Messages { get; set; }

   // contains data that you want to get back
   public NewMessage NewMessage  { get; set; }
}

// represents a new message
public class NewMessage
{
    [StringLength(100)]
    string MessageComposer { get; set ;}
}

Ваш вид (упрощенная версия)

@model ForumMessageViewModel

<!-- render the messages -->

...

<!-- entry for new message -->

@using (Html.BeginForm("AddMessage", "ForumController"))
{
    <div>
        @Html.LabelFor(m => m.NewMessage.MessageComposer)
    </div>
    <div>
        @Html.TextBoxFor(m => m.NewMessage.MessageComposer)
        @Html.ValidationMessageFor(m => m.NewMessage.MessageComposer)
    </div>
    <p>
        <input type="submit" value="Submit new message" />
    </p>    
}

Затем вы можете использовать префикс привязки на вашем контроллере ...

public ViewResult AddMessage([Bind(Prefix="NewMessage")] NewMessage newmessage)
{
    // logic to save 
}
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...