от модели домена до сценария транзакции

Question

Новое место, где я начал, только начинает разрабатывать совершенно новый продукт с нуля.Они выполняют сценарий транзакций в сервисах приложений, полностью тупые сущности и DAL с хранимыми процедурами (аргумент состоит в том, что nhibernate плохо оптимизирует sql, загружает слишком много вещей, плохо масштабируется для больших проектов и т. Д. И т. Д. И т. Д. И т. Д. И т. Д.).приложение должно быть ОГРОМНЫМ проектом только в зачаточном состоянии.

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

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

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

Answer 1

Я бы сказал, что взятие материала для его подкрепления - путь, по которому они не могут использовать вашу неопытность в качестве аргумента (хотя мне кажется, что вы не особенно неопытны или младше!).Моим основным рекомендацией была бы эта книга:

http://www.amazon.co.uk/Microsoft-NET-Architecting-Applications-PRO-Developer/dp/073562609X/ref=sr_1_1?ie=UTF8&qid=1317121019&sr=8-1

На странице 146 говорится:

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

Это не описывает систему, над которой вы работаете.

Далее описывается Модель предметной области и почему она подходит для больших систем.

Я хотел бы спросить, понимаете ли вы, что они выбирают сценарий транзакций?По моему опыту, TS может быть выбором по умолчанию для неопытных организаций, которые даже не понимают, что есть даже вариант.Они просто думают «вот как это делается».Насколько успешным и поддерживаемым является их текущий код?Если бы они выбирали TS для огромных проектов, я думаю, что «не очень»Они обвиняют клиента в изменении спецификаций, когда что-то идет не так?Если это так, это свидетельствует о том, что они неправильно выбрали архитектуру.

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

Кроме того, в наше время серверы баз данных должны иметь возможность обрабатывать системы, основанные на NHibernate, без проблем.Если это невозможно, то это проблема с сервером базы данных.И как они собираются провести модульное тестирование этих хранимых процедур?Я обычно нахожу, что SP - единственная самая большая ошибка разработчика.

Как сказал Магнус, я мог бы просто продолжать и продолжать об этом.Я не знаю деталей системы, но как только вы используете слово ОГРОМНОЕ, доменная модель становится наиболее очевидным выбором.

Answer 2

В дополнение к тому, что Пол Т Дэвис и Магнус Бакеус .Я думаю, что в конце концов это будет проблема людей и культуры.Если люди открыты и готовы учиться, их будет относительно легко убедить.Если они считают вас «младшим» (что является плохим признаком, потому что важно только то, что вы говорите, а не сколько вам лет / лет), вы можете обратиться к «высшему авторитету»:

• Шаблоны корпоративной архитектуры приложений
• Домен-управляемый дизайн
• Растущее объектно-ориентированное программное обеспечение
• Внедрение зависимостей в .NET

Хранимые процедуры мертвы, и вы не единственный, кто так думает :

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

Нет смысла убеждать людей, которые не хотят совершенствоваться и учиться.Например, даже если вам удастся выиграть один аргумент и втиснуть его в NHibernate, они могут в конечном итоге написать такой же тесно связанный, непроверяемый, ориентированный на данные или linq код, как и раньше.DDD сложен и потребует изменения множества предположений, нанесения вреда эго и т. Д. В зависимости от размера компании, это может быть постоянная битва, которую не стоит начинать.

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

• Неинформированный
• Стадо
• Циник
• Сожженный
• Время хрустит
• Босс
• Иррациональное

Удачи!

Answer 3

Ну, всегда есть две стороны медали. У них могут быть некоторые моменты, касающиеся Nhibernate и проблем с производительностью. Но всегда есть решения для этого, такие как стратегии загрузки, где вы точно указываете, как Nhibernate должен выполнять конкретные критические запросы. С помощью стратегий загрузки, кэширования и настройки индексов sql вы можете значительно повысить производительность. Но истинное преимущество ORM состоит в том, что он уменьшает кодовую базу и делает ее более СУХОЙ. Делает вашу систему более удобной в обслуживании. Это также уменьшает «слой», так как вам не нужны хранимые процедуры.

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

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

• Логика легко выдвигается к графическому интерфейсу

Я могу сделать список длиннее ... но я хочу сказать, что люди склонны выбирать сценарий транзакции иногда просто потому, что его легко понять, начать с него и, что очень хорошо, он может хорошо работать. НО, как правило, проблемы возникают, когда консультанты, сотрудники покидают проект, а команда технического обслуживания вступает во владение. Часто не ясно, где следует вносить изменения, и большинство приложений TS, которые я видел, подвергались архитектурному насилию. Они были хорошими приложениями с самого начала, но с тех пор приглашают вас поместить логику в SP, сервисы, GUI (из-за отсутствия ограниченных API, интерфейсов и т. Д.).

Ты следишь за мной? / Magnus

p.s Вы можете получить отличную производительность и DDD с подходом CQRS ...