Требуется некоторое руководство по архитектуре ASP.NET MVC 3

Question

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

Начну с того, что я не использую платформу сущностей или какой-либо ORM - я бы хотел напрямую реализовать свои собственные бизнес-объекты и код доступа к данным (используя ADO, SPROCS и т. д.).) чтобы они были оптимальными, это личное предпочтение.Вот где я изо всех сил пытаюсь найти непротиворечивую информацию, поскольку, как представляется, большая часть информации относится к использованию LINQ to SQL или Entity Framework.

МОЕ приложение было структурировано со следующими проектами:

• Web (веб-приложение MVC 3)
• Модели (библиотека классов)

Есть только два проекта, потому что у меня проблемы с развязкой вещей;это корень моего вопроса.Моя библиотека классов моделей содержит…

• классические бизнес-объекты с полями и свойствами
• Класс репозитория для каждого бизнес-объекта, который содержит код доступа к данным (прямолинейные ADO.NET SqlDataReaders и т. Д.)
• Интерфейс для каждого класса репозитория

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

1.Бизнес-объекты должны содержать методы, которые реализуют бизнес-логику, поэтому помимо полей и свойств существуют методы для реализации любой требуемой логики?

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

3.Theконтроллеры (на веб-уровне) используют интерфейсы репозитория, но почему?Они не должны содержать бизнес-логику, «модель» или бизнес-объект должен?Контроллеры, конечно, не должны содержать бизнес-логику, так что опять-таки это неправильноМне не нужна бизнес-логика в репозиториях, поскольку они попадают в базу данных.

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

Answer 1

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

Например, проекты могут быть структурированы следующим образом: -

Базовая библиотека

Это было бы простоPOCO, которые представляют данные вашего домена и взаимодействуют с любыми услугами.Здесь нет бизнес-логики.Просто простые свойства.

например.

открытый класс User {public int UserId {get;задавать;} публичная строка Name {get;задавать;}}

- Core
      \Entities <-- Poco's
      \Services <-- Interfaces for services

Службы

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

Репозиторий

Здесь вы делаете базовые вещи базы данных.Вы сказали, что не используете L2S или EF и т. Д. Никаких пробников.Я бы серьезно отнесся к использованию Micro-ORM вместо этого, например Dapper или Massive .

Тесты

Вы выполняете юнит и интеграциютесты, верно?я рекомендую xUnit или nUnit для среды тестирования.

Веб-приложение

Это приложение MVC3.Я бы рекомендовал использовать StructureMap для инъекции зависимостей.(Вы используете IoC / DI, верно?)

Сначала вы можете подумать -> это ОЧЕНЬ много проектов, верно?ну, это легко разделить на ДВА проекта.

1. Веб-приложение
2. Тестовый проект

и Базовая библиотека, Сервисы, Репозиторий - все существуетв проекте веб-приложения в виде папок.

Попробуйте и не перегружайте решение Visual Studio.Большинство людей думают, что им нужно много проектов и дерьмовую кучу абстракций ... потому что это то, что они думают, что все остальные делают, и это правильно.Что ж, этот ход мыслей начался в самом начале 2000-х годов ... и в 2012 году с тех пор изменилось много шизов.

Попробуйте использовать DI / IoJ, NuGet для загрузки этих библиотек в ваше решение, Micro-OR /М для доступа к данным и тестирование проекта.

Несколько проектов, чтобы проверить, re: как все изложено:

1. JabbR.net
2. RavenOverflow

Answer 2

Я думаю, что начинать с малого - это хорошо, а затем, когда возникнет необходимость, вы начнете расширять свой обзор и начинаете разделять слои по мере необходимости. Зачем разделять вашу работу на 20 проектов, если у вас есть 2 модели, 1 представление и одна таблица для запроса и обновления в базе данных.

Начните с малого и позвольте «необходимости» управлять проектом. Если вам нужно читать / писать множество таблиц в базе данных, возможно, сейчас самое время начать использовать шаблон репозитория. Вы обнаружите, что вам нужно как минимум 10 или более различных моделей, возможно, пришло время внедрить библиотеку, содержащую DTO / модели и вывести их из веб-приложения.

Если, например, вам требуется написать модульные тесты или выполнить TDD, вы обнаружите, что возможность мгновенно смоделировать хранилище, бизнес и сервисный уровень пригодится.

Ради аргумента я видел проекты, похожие на приведенные ниже (но большинству не нужен такой уровень разделения):

• веб-проект; использование сервисной библиотеки и библиотеки dto
• Сервисная библиотека; использование библиотеки бизнес-уровня и библиотеки dto
• библиотека бизнес-уровня; использование библиотеки репозитория, библиотеки сущностей и библиотеки dto
• Библиотека репозитория; использование библиотеки объектов
• Библиотека сущностей
• Библиотека dto

Большинство из них были еще более разбиты на отдельные библиотеки, содержащие интерфейсы в одной и реализации в другой и так далее. В некоторых проектах, над которыми я работал, было более 50 библиотек, которые отделяли большинство, если не все, но всегда основывались на требованиях или потребностях.

Идея вышеприведенного примера состоит в том, чтобы веб-приложение просто обрабатывало передачу DTO в сервисный вызов и получение DTO обратно из сервисного вызова.

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

Служба запускается и вызывает метод в менеджере, передавая DTO, который находится в библиотеке бизнес-уровня. Этот менеджер будет использовать DTO и сопоставлять его с одним или несколькими объектами и вызывать методы в хранилище, передавая эти объекты. Хранилище возвращает сущности, которые менеджер использует для создания DTO для отправки обратно.

Есть много способов сделать это, и я уверен, что ни один из них не является единственно правильным.

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

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

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

Answer 3

1. возможно, если модель этого требует.большинство моделей - простые dtos с общедоступными свойствами.но вы могли бы так же легко инкапсулировать некоторые из них.

2. не совсем так.репозиторий - это коллекция бизнес-объектов.он может создавать экземпляры этих объектов из базы данных.

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

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

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

Answer 4

Несколько моментов:

• Нет проблем с наличием «бизнес-логики» в ваших репозиториях.На самом деле большая часть вашей «бизнес-логики» будет там.Ваши репозитории содержат запросы, и если эти запросы вообще интересны, то эти запросы будут тесно связаны с вашей «бизнес-логикой».

• Нет проблем с наличием «бизнес-логики»в ваших контроллерах.Ваши контроллеры контролируют ваш пользовательский интерфейс, и то, как ваш пользовательский интерфейс работает, является «бизнес-логикой».

• По определению, в многоуровневой архитектуре каждый уровень знает об открытом интерфейсе уровня над ним.Ваш доступ к данным может видеть общедоступный интерфейс вашего уровня домена.Ваш уровень пользовательского интерфейса может видеть открытый интерфейс вашего уровня обслуживания.

• Если ваш проект настолько мал, что вы можете позволить себе кодировать собственный слой доступа к данным, а не использовать ORM или подобноетогда полностью отделенная архитектура Starship Enterprise, вероятно, только сделает вашу жизнь труднее всего.(И под этим я подразумеваю, что я думаю, что вы с ума сошли, когда пишете свой собственный слой доступа к данным - по крайней мере, попробуйте облегченный фреймворк, такой как Dapper).

• Основывайте свой выбор натвои нужды.Спросите себя: «Почему X нужно отделить от Y».Ответ может быть таким: «Так что я могу смоделировать X, когда я тестирую Y».Ответ может быть таким: «Поэтому я могу использовать X в моем другом проекте, который не должен знать о Y».Если вы не можете найти ответ, то ЯГНИ.