Наименование проекта

Question

Как начинающий / промежуточный разработчик, я сталкиваюсь с одной проблемой, когда мои проекты становятся все больше и больше отвлекаются, когда я использую больше принципов ООП. Например, когда у меня есть несколько проектов или библиотек классов, я не знаю, как их назвать. Я вижу вещи от xxx.Core до xxx.Main или даже видел xxx.BLL и xxx.DAL. Просматривая другие, я видел xxx.Services и xxx.Data для их библиотеки и пространств имен.

Тогда, когда это решено, что я могу назвать DTO? В этом мире я видел xxx.DTO, xxx.Entities, xxx.Props.

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

Answer 1

Аббревиатуры вообще плохие.

Уровень доступа к данным
YourCompany.Data.dll

Слой сущности
YourCompany.Data.Entities.dll

Бизнес-уровень
YourCompany.BusinessLogic.Name.dll (пример: YourCompany.Accounting.Services.dll)

Это тоже не золото, я уверен, что есть много других способов, которыми вы можете сделать это, мы делаем это, так что гораздо проще найти проект, сборки и построить правильные развертывания. Кроме того, при просмотре ваших сборок гораздо удобнее видеть полные имена, чем «MS.BLL.dll».

Answer 2

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

Answer 3

Эй,% 20, рад видеть тебя здесь :) (при условии, что ты один из 3dbuzz)

Так или иначе, используйте пространства имен и папки! Не сходите с ума от DLL, если вам это не нужно. Для приложений, которые, я полагаю, вы говорите о библиотеках DLL, вероятно, будут излишними. В C # используйте папки и пространства имен. Например:

Library
 - Net code
 - DBA code
 - Controller manager code
 - Factories
Application
 - Forms
 - Controllers
 - Models
  - Helpers

В C ++ я обычно:

Library
 - Net Code
  - Header Files
  - Source Files
  - Inline/template files
 - DBA Code
  - Header Files
  - Source Files
  - Inline/template files
Application
 -Model
  - Header Files
... and so on

В PHP сложнее без пространств. Но я все еще придерживаюсь той же структуры папок, что и в C #, но я называю свои классы, чтобы компенсировать отсутствие пространств имен. Например, если бы в C # у меня был класс «Index» в пространстве имен Application.Controllers.Course, в PHP я бы назвал его:

Application_Controllers_Course_Index

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

Answer 4

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

Answer 5

Вы можете получить некоторые идеи по структурированию пакетов здесь: Структура пакета для проекта Java?

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