DDD, NHibernate и структура проекта / именование

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

Я бы начал с pylint, с его расширениями . В Github есть программа проверки образцов. Хорошим моментом здесь является то, что вы можете включить это в инструменты CI / CD без особой работы. Проблема здесь может заключаться в том, что компоновщик может быть проинформирован, чтобы не рассматривать что-то как проблему. С одной стороны, это прекрасно, так как md5 может использоваться в некоторых областях, но это может привести к утечке ... Если смотреть таким образом, все, что вы можете сделать, это сообщить.

Другой вариант - проверка безопасности, которая может работать с кодом Python. Я использую lynis на моем сервере. Они используют обычную оболочку Linux. На практике вы можете grep написать код на python, чтобы увидеть, что там что-то не так. Я бы посоветовал пойти туда и проверить, что они ищут и как это делается. Если не пойти по этому пути - чем, может быть, для вдохновения. Ложные срабатывания также должны быть рассмотрены здесь. Итак, вопрос в том, хотите ли вы разобраться с этим самостоятельно или действительно с разработчиками ...

Я бы начал с некоторых проверок - таких как md5 / sha1, а затем расширил. Обязательно понятно, что проверено, а что нет. Это выглядит действительно сложно, но я бы попробовал. Может быть, расширение с открытым исходным кодом до pylint, на github? Таким образом, вы можете получить поддержку от других! Если так - дайте мне знать:)

7
задан BuddyJoe 13 April 2009 в 21:38
поделиться

3 ответа

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

  • Sample.Core - сервисы и код, которые необходимо использовать в приложении
  • Sample.Data - доменные классы и интерфейсы репозитория
  • Sample.Data.NHibernate - сопоставление файлов, свободный config и т. д. и реализации репозитория, в основном все, что связано с уровнем отображения данных
  • Sample.Services - реализации и интерфейсы служб
  • Sample.Web - веб-приложение

У меня есть соответствующее дерево тестовых проектов:

  • Tests \ Sample.Core.Tests
  • Tests \ Sample.Data.NHibernate.Tests
  • и т. Д ...

Конечно, дерево будет более сложным в зависимости от проекта. Что касается обсуждений, ознакомьтесь с Луковой архитектурой .

3
ответ дан 7 December 2019 в 05:30
поделиться

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

  • Sample - содержит пространства имен Sample.Model, Sample.Model.Mappings и Sample.Services.
  • Sample.Tests - содержит модульные тесты, структурированные так же, как Sample.
  • Sample.Web - пользовательский интерфейс
2
ответ дан 7 December 2019 в 05:30
поделиться

Я обнаружил, что у каждого есть свои предпочтения именования, я предпочитаю:

  • Sample.Domain - доменные объекты, файлы сопоставления
  • Sample.Services - бизнес-логика и службы (и репозитории, хотя я мог видеть их разделение)
  • Sample.Web - Web Stuff.
  • Sample.Migrations - Миграция данных.

Бен Шейрман также недавно было опубликовано сообщение об этом: Экспорт решений Visual Studio с помощью Factory Factory .

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

2
ответ дан 7 December 2019 в 05:30
поделиться
Другие вопросы по тегам:

Похожие вопросы: