Я все еще пытаюсь выяснить правильную архитектуру для сложного ASP.NET веб-приложение MVC.
Я смотрел в большом количестве примера кода, и везде он сделан по-другому.
Я был бы очень признателен за Ваши мысли об этом.
Другой Вопрос: Вы использовали бы Linq для SQL или Платформы Объекта?
Спасибо,
- Ben
Ознакомьтесь с этим Руководство по архитектуре: ASP.NET MVC + N-tier + Entity Framework и многое другое
Если вы хотите использовать ASP.NET MVC, но изо всех сил стараются получить что-то аранжируйте, чтобы уверенно использовать его в своем следующем бизнес-проекте. Эта статья специально для вас. Эта статья поможет вам использовать ASP.NET MVC для создания небольшой системы управления документами.
Некоторые личные мысли и опыт:
- Используйте nhibernate как orm, или подождите EF v4. Tekpub.com имеет хорошее учебное пособие по использованию NH. L2S и EF - это своего рода черный ящик: они много чего делают, у них хорошая документация, но у них нет точки расширения. Если Вы хотите подключить какую-то новую функциональность или изменить поведение, Вы можете сделать это только с NH. EF в v4 будет в состоянии, в котором NH был 2 или 3 года назад.
- Просмотрите как можно больше примеров MVC-приложений. Многие из них вы можете найти в кодеплексе. Например: CodeCampServer, WhoCanHelpMe, Storeddd
.
- Если вы думаете о создании фреймворка (или помощника) для решения некоторых проблем с инфраструктурой, сначала обратитесь к гуглу; высока вероятность, что у кого-то, кто умнее вас (ну, в моём случае, умнее меня), уже были такие же проблемы, и написали хороший кусок кода в виде фреймворка (object mapper, validation, messaging,...), или просто написали об этом в блогах.
- Использование острой архитектуры или fubuMvc решает большую часть инфраструктурной работы, но остальная часть приложения зависит от вашей бизнес-модели.
- TDD заставит вас писать хороший и удобный в обслуживании код. Попробуйте как можно больше использовать шаблоны дизайна Gang of Four и принципы SOLID.
Поскольку вы собираетесь использовать MVC-приложение, вы можете легко записать слой DataAccess под слоем контроллера. Таким образом, это будет слоистое приложение . Таким образом, это может быть подходящим вариантом для вашей архитектуры.
Для вопроса LinQ-SQL или Entity Framework я использовал только Entity framework. Так что не уверен насчет опции Linq to Sql. Но есть определенные проблемы с фреймворком Entity Framework при изменении схемы. Повышение сгенерированной edmx не происходит корректно при переименовании столбцов и т.д. Поэтому я удаляю и создаю edmx после каждого изменения схемы, и вы должны вручную обновлять изменения там.
Вы бы использовали Linq to SQL или Entity Framework?
Linq2SQL отлично подходит, если вы хотите получить доступ к объектной модели, которая непосредственно отображается в вашей базе данных. Например, если у вас есть таблица "Приказы", Linq2SQL создаст объект "приказы", который вы можете использовать для доступа к данным. Часто это полностью адекватно.
Entity Framework полезен, когда вы хотите создать объектную модель, которая может не отображаться непосредственно в базе данных.
Везде отличается от . На этот вопрос нет универсального ответа. Посмотрите на другие подходы, и возьмите у них все, что считаете полезным для вашей ситуации.