Могу ли я использовать пример проекта NerdDinner в качестве базового шаблона для более крупного проекта?

Question

Я новичок в инфраструктуре MVC и только что прошел пример проекта NerdDinner. Мне нравится этот подход по сравнению с asp.net на основе форм.

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

Примеры вещей, которые меня насторожили: 1) Образец NerdDinner обращается к БД только из двух таблиц, у моей БД около 30. 2) Проект NerdDinner использует классы LinqToSQL напрямую ... на всем пути от модели, через контроллер, к представлению ... это кошерное для большого проекта?

Видите ли вы какие-либо другие части фреймворка NerdDinner, которые могут вызвать у меня будущее горе?

Answer 1

Я согласен с другими, что модель должна быть единственным местом, где вы используете linq2sql, и мое небольшое дополнение к этому - использовать только linq2sql в моделях небольших проектов. Для более крупных сайтов может оказаться целесообразным создать отдельный проект веб-службы, который будет взаимодействовать с базой данных и использовать веб-службу в вашей модели.

Я никогда полностью не извлекал пример Nerd Diner, но другие лучшие практики включают в себя типизированные представления и использование модуля моделирования данных, который упрощает проверку (см. xval или DataAnnotations связыватель модели). Для меня это 2 из наиболее важных лучших практик /

Стивен Уолтер имеет на своем сайте замечательные советы, которые стоит проверить и учесть при создании нового проекта MVC.

Answer 2

Я бы добавил сервисный слой между репозиториями и контроллерами. Уровень обслуживания будет содержать всю вашу бизнес-логику, оставляя вашим контроллерам заниматься главным образом обработкой входных данных формы и потоком страниц.

В репозиториях я сопоставляю классы и поля LinqToSql с моделями доменов, а затем использую модели доменов на уровне сервиса, контроллерах и представлениях. Для более крупной системы дополнительные слои докажут свою ценность в долгосрочной перспективе.

Answer 3

В Интернете много споров, когда речь заходит о классах Linq to Sql. Некоторые считают, что недостаточно абстракции, когда вы используете классы напрямую, а некоторые считают, что для этого они и нужны. На работе мы начинаем модернизацию нашего сайта, и мы используем MVC. Путь, по которому мы решили пойти, заключался в том, что каждый класс LINQ to SQL реализует интерфейс. IE:

public partial class LinqToSqlClass //generated class
{
   public int Id{get;set;}
}

interface ILinqToSqlClass
{
   int Id{get;set;}
}

public partial class LinqToSqlClass : ILinqToSqlClass
{

}

Это всего лишь малая часть. Затем у нас есть репозиторий, который получает любой из этих сгенерированных классов, но только в виде интерфейса этого типа. Таким образом, мы никогда не работаем напрямую с классами Linq to Sql. Есть много разных способов сделать это, но обычно я бы сказал да, если вы имеете дело с большой базой данных (особенно если схема может измениться) или если вы имеете дело с данными, которые могут поступать из более чем одного источника определенно не используйте классы напрямую.

Суть в том, что в этой главе Nerd Dinner есть много полезной информации, но при создании собственного проекта вы, очевидно, столкнетесь с собственными проблемами, так что принимайте их как есть.

Answer 4

В тексте Nerd Dinner утверждается, что среда MVC может в равной степени приспособиться к другим распространенным абстракциям данных. (Это правда.) Похоже, у вашей организации уже есть тот, который ей нравится. Хорошей стратегией обучения, вероятно, будет адаптация одного к другому.