Здравствуйте, Shmj, Вы писали: S>Вот, есть в проекте папка "Service/Services". Как вы думаете, что в ней размещено?
Все, что угодно.
На самом деле проблема глубже. Декомпозиция модели, обычно, идет двумя (как минимум) направлениями — по предметной области и по паттернам. Это уже создает неудобство. По хорошему, в папке Services должно лежать что-то связанное с услугами, которые предполагаются в предметной области проекта. Но название чего-либо в проекте может отражать не только предметную область, но и паттерны. Это, на самом деле, достаточно паршиво, но программисты знакомы с паттернами проектирования и их мозг может разделить паттерны и предметную область в большинстве случаев. Кроме этого — "служба" достаточно общий паттерн, который по сути не описан. Это может быть частью SOA, это могут быть утилиты, это могут быть службы доступа к БД, это может быть всё, что угодно. Такой себе контрольный выстрел в ногу — мы не только выбрали для названия пространства в проекте слово не из предметной области, но и выбрали названием достаточно общее слово, чтобы сломать себе мозг.
Всё, что нас не убивает, ещё горько об этом пожалеет.
Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, mogikanin, Вы писали:
M>>Сервисы сервиса?
S>Вообще папка Service ИЛИ Services имелось в виду. Что за сервисы?
Вам виднее что у вас за сервисы.
Re[4]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, mogikanin, Вы писали:
M>>Вам виднее что у вас за сервисы.
S>Вот в этом и вопрос. Что понимать под сервисами?
Лучше всего избегать таких общих названий.
А то некоторые даже умудряются создавать папочки "Classes", "Enums" и "Forms".
Re[6]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, mogikanin, Вы писали:
M>Лучше всего избегать таких общих названий. M>А то некоторые даже умудряются создавать папочки "Classes", "Enums" и "Forms".
А как насчет названий View, Model, ViewModel, Utils? Обычно среди этих папок и папка Services.
Re[7]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, Shmj, Вы писали:
S>А как насчет названий View, Model, ViewModel, Utils? Обычно среди этих папок и папка Services.
Обычно? Ни разу не встречал в нормальном коде.
А папки View/Model/ViewModel в одном проекте (csproj) смотрятся очень убого. Если хочется разделения, лучше заводить три проекта, имхо.
Re[8]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, mogikanin, Вы писали:
M>Обычно? Ни разу не встречал в нормальном коде. M>А папки View/Model/ViewModel в одном проекте (csproj) смотрятся очень убого. Если хочется разделения, лучше заводить три проекта, имхо.
А вы ввобще разработкой давно занимаетесь? Я тоже, лет 8 назад, спешил дать совет согласно своим суевериям и предубеждениям, которые никак практикой не были подтверждены.
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, mogikanin, Вы писали:
M>>Обычно? Ни разу не встречал в нормальном коде. M>>А папки View/Model/ViewModel в одном проекте (csproj) смотрятся очень убого. Если хочется разделения, лучше заводить три проекта, имхо.
S>А вы ввобще разработкой давно занимаетесь? Я тоже, лет 8 назад, спешил дать совет согласно своим суевериям и предубеждениям, которые никак практикой не были подтверждены.
S>Один из образцовых проектов MVC: http://nerddinner.codeplex.com/SourceControl/latest. Какие папки вы там видите?
S>Models, Views, Controllers, Filters, Helpers, Services
8 лет позанимались разработкой, и задаете вопросы о именовании папок в проектах?
Повторюсь еще раз, нет смысла в папках ради папок и супер-мега-структуризации проекта.
Ну и имена следует давать такие, чтоб из контекста проекта было понятно, о чем речь.
Re[10]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, mogikanin, Вы писали:
M>8 лет позанимались разработкой, и задаете вопросы о именовании папок в проектах?
Именно. Осознание важности четкой и однозначной структуры приходит далеко не сразу.
Сначала все создают структуру от балды и не видят в этом проблемы.
M>Повторюсь еще раз, нет смысла в папках ради папок и супер-мега-структуризации проекта.
Молодой человек, речь не о "супер-мега-структуризации". Разбиение на пространства имен, группировка -- это важнейшая часть любого проекта.
M>Ну и имена следует давать такие, чтоб из контекста проекта было понятно, о чем речь.
Model, View, Utils -- всем понятно, потому что есть неписанное соглашение. К подобной категории я бы отнес и Service, но с ним есть проблемы. Именно это и обсуждается.
Re[11]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, mogikanin, Вы писали:
M>>8 лет позанимались разработкой, и задаете вопросы о именовании папок в проектах? S>Именно. Осознание важности четкой и однозначной структуры приходит далеко не сразу.
После 8 лет к вам пришло озарение? Сочувствую. Но лучше поздно чем никогда.
M>>Ну и имена следует давать такие, чтоб из контекста проекта было понятно, о чем речь. S>Model, View, Utils -- всем понятно, потому что есть неписанное соглашение. К подобной категории я бы отнес и Service, но с ним есть проблемы. Именно это и обсуждается.
Вам уже несколько раз сказали, что Service — неудачное имя, если из контекста проекта неясно что имеется в виду.
Re[12]: Неоднозначность термина "Service" в контексте структуры проекта
Здравствуйте, mogikanin, Вы писали:
M>>>8 лет позанимались разработкой, и задаете вопросы о именовании папок в проектах? S>>Именно. Осознание важности четкой и однозначной структуры приходит далеко не сразу.
M>После 8 лет к вам пришло озарение? Сочувствую. Но лучше поздно чем никогда.
Да вопрос то не в том.
M>>>Ну и имена следует давать такие, чтоб из контекста проекта было понятно, о чем речь. S>>Model, View, Utils -- всем понятно, потому что есть неписанное соглашение. К подобной категории я бы отнес и Service, но с ним есть проблемы. Именно это и обсуждается. M>Вам уже несколько раз сказали, что Service — неудачное имя, если из контекста проекта неясно что имеется в виду.
Ну вам и Model, View, Utils -- не понятны. А для меня, к примеру, Service имеет довольно однозначное значение. Проблема в том, что, похоже, не для всех это значение однозначно.
