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

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

0 голосов
/ 17 сентября 2011

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

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

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

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

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

Ответы [ 2 ]

0 голосов
/ 17 сентября 2011

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

  • ProductName
  • 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 эта функция была настолько велика, она была приспособлена для собственной библиотеки для более удобного управления.

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

0 голосов
/ 17 сентября 2011

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

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

Например:

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

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

...