При создании приложения N-уровня, как мне организовать свои пространства имен?

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

Один из парней, который ответил на вопрос, сказал мне, что если вы примените хорошую архитектуру, вы получите еще лучшую производительность. Это связано с компиляцией dll и прочего, но теперь я не уверен, как назвать мои пространства имен.

Как у меня есть основное пространство имен для моего уровня доступа к данным, так что, скажем, у меня есть это пространство имен в качестве моего уровня данных..DAL

но теперь у меня есть более чем сущность в приложении, которая должна обслуживаться этим уровнем, и у каждой сущности есть свои меньшие сущности.

поэтому я должен включить весь код данных в одно пространство имен (DAL) или каждый объект должен иметь свое собственное пространство имен, например DAL.E1 и DAL.E2, или каждый основной или дочерний объект должен иметь свое собственное пространство имен, например DAL.E1.c1, DAL.E2, DAL.E3.c1, DAL.E3.c2.. последний вопрос, должен ли сам DAL включать какие-либо классы или нет?

Источник

2 ответа

Решение

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

  • Наименование товара
  • ProductName.Activation
  • ProductName.Activation.Service
  • ProductName.Core
  • ProductName.Data
  • ProductName.Data.Customers
  • ProductName.Data.Engine
  • ProductName.Instrumentation
  • ProductName.Security
  • ProductName.ShellUI
  • ProductName.ShellUI.Windows
  • ProductName.Win32

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

Другие предпочитают давать своим сборкам очень короткие имена, что по-прежнему делается даже сегодня Microsoft. (например, mscorlib.dll).

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

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

Мое предложение состоит в том, чтобы организовать его по функциям, потому что это облегчает управление проектом. Вы знаете, что Module1 обрабатывает Part1 системы, а Module2 обрабатывает Part2 и так далее. Примером будет ProductName.Data.dll. В моем проекте он обрабатывает все связанные с данными операции, такие как настройки, настройки и взаимодействие с базой данных, в то время как ProductName.Data.Engine - это инфраструктура, которая позволяет ProductName.Data легко взаимодействовать с уровнем данных. (В этом случае ProductName.Engine - это материал Entity Framework с другими пользовательскими классами и необходимыми частями платформы).

Я предполагаю еще одно практическое правило, которое я придерживаюсь, если в Module1 есть много частей, составляющих часть 1 приложения, я бы оставил все это в Module1. Если только в ProductName.Data.Engine эта функция была настолько велика, она была приспособлена для собственной библиотеки для более удобного управления.

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

Источник

Хм... это больше похоже на проблему организации.

Я обычно предпочитаю организовывать элементы в одном пространстве имен (классы, структуры, ...) по функциональности в системе, а затем, если необходимо, группировать типы объектов.

Например:

  • App.Domain; // Доменные объекты
  • App.Domain.Authentication; // Доменные объекты, связанные для аутентификации
  • App.Domain.Repository; // Репозиторий реализации
  • App.Domain.Repository.Mapping; // Mappings (например, NHibernate HBM репозитория)
  • App.Services; // открытая функциональность системы
  • App.Controllers; // контроллеры вида
  • App.Controllers.Flex; // контроллеры, специализированные для flex

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

Источник
Другие вопросы по тегам