структура кода разработки .net -Контроллеры, службы, репозитории и контексты - PullRequest
3 голосов
/ 11 декабря 2010

Как новый разработчик, я полностью смущен именами и структурными соглашениями для разработки кода на c # с использованием передового опыта.

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

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

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

Какое программное обеспечение / инструменты мне действительно нужно искать для разработки качественного кода?Модульное тестирование, непрерывная интеграция, Resharper, инструменты Mocking, контейнеры DOI, nHibernate.

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

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

Спасибо

Ответы [ 2 ]

1 голос
/ 11 декабря 2010

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

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

Обычно я организовывал свою модель, создавая некоторую папку (пространство имен) для ее достижения. Вот моя модель:

  • Репозиторий: будет выполнять только запрос, вставить, обновить и удалить один стол (интерфейс и инвентарь).
  • Услуги: сочетание таблицы, основанные на репозитории, делают вход и выход и некоторые другие которые не связаны с доступом к базе данных.
  • Классы: объявленный объект.
  • Утилиты: статические функции перенаправляют из репозитория и могут вызываться с помощью View.

Может быть, вы можете поделиться своим !!

0 голосов
/ 11 декабря 2010

Для модульного тестирования есть NUnit. Для непрерывной интеграции есть CruiseControl.net Для насмешек есть Moq или RhinoMocks, лично я считаю Moq проще и легче в освоении. Для DI есть Ninject, Structuremap и некоторые другие, я предпочитаю StructureMap. Это те, которые я использовал, и обычно есть несколько вариантов.

Если вам нужна хорошая книга, которая поможет вам освоить ASP.NET MVC, общие шаблоны проектирования, такие как шаблон репозитория, и разработать тестируемый код, я рекомендую Pro ASP.NET MVC 2

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

...