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

Я не уверен, что объекты сущностей должны существовать.

Под объектами сущности я подразумеваю типичные вещи, которые мы склонны создавать для наших приложений, такие как «Персона», «Учетная запись», «Заказ» и т. Д.

Моя нынешняя философия дизайна такова:

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

(Примечание: я также создавал корпоративные приложения с Java EE, Java-пользователи, пожалуйста, замените эквивалент для моих примеров .NET)

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

Я не строю игрушки. Я говорю о больших и больших объемах транзакционных приложений, развернутых на нескольких машинах. Веб-приложения, службы Windows, веб-службы, взаимодействие b2b, вы называете это.

Я использовал OR Mappers. Я написал несколько. Я использовал стек Java EE, CSLA и несколько других эквивалентов. Я не только использовал их, но и активно разрабатывал и поддерживал эти приложения в производственных средах.

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

Рассмотрим этот простой пример: вы получаете звонок в службу поддержки по поводу определенной страницы в вашем приложении, которая работает неправильно, возможно, одно из полей не сохраняется, как должно быть. С моей моделью открывается разработчик, которому поручено найти проблемуровно 3 файла, ASPX, ASPX.CS и файл SQL с хранимой процедурой. Проблема, которая может быть отсутствующим параметром при вызове хранимой процедуры, занимает несколько минут. Но в любой модели сущностей вы неизменно запустите отладчик, начнете пошагово выполнять код, и у вас может получиться 15-20 файлов, открытых в Visual Studio. К тому времени, когда вы спуститесь на дно стека, вы забыли, с чего начали. Мы можем хранить столько вещей в наших головах одновременно. Программное обеспечение невероятно сложное без добавления ненужных слоев.

Сложность разработки и устранение неполадок - это только одна из сторон моего понимания.

Теперь поговорим о масштабируемости.

Понимают ли разработчики, что каждый раз, когда они пишут или изменяют какой-либо код, взаимодействующий с базой данных, им необходимо провести тщательный анализ точного воздействия на базу данных? И не только копия для разработки, я имею в виду имитацию производства, поэтому вы можете видеть, что дополнительный столбец, который вам сейчас нужен для вашего объекта, только что сделал недействительным текущий план запроса, а отчет, который выполнялся за 1 секунду, теперь займет 2 минуты, просто потому что вы добавили один столбец в список выбора? И получается, что индекс, который вам сейчас нужен, настолько велик, что администратору БД придется изменить физическую структуру ваших файлов?

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

Я не фанатик. Я могу быть уверен, что ошибаюсь, а может, и так, потому что есть такой сильный толчок в сторону Linq к Sql, ADO.NET EF, Hibernate, Java EE и т. Д. Пожалуйста, продумайте свои ответы, если я что-то упустил очень хочу знать, что это такое, и почему я должен изменить свое мышление.

[Редактировать]

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

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

В ответ на несколько аналогичных ответов я должен отметить одну вещь: ортогональность и разделение интересов часто приводятся в качестве причин для перехода к сущности / ORM. Для меня хранимые процедуры - лучший пример разделения проблем, о которых я могу думать. Если вы запретите любой другой доступ к базе данных, кроме как через хранимые процедуры, теоретически вы можете перепроектировать всю модель данных и не нарушать никакого кода, если вы поддерживаете входные и выходные данные хранимых процедур. Они являются прекрасным примером программирования по контракту (если только вы избегаете «select *» и документируете наборы результатов).

Спросите кого-нибудь, кто уже давно работает в отрасли и работал с долгоживущими приложениями: сколько уровней приложений и пользовательского интерфейса появилось и ушло, пока база данных дожила? Насколько сложно настроить и реорганизовать базу данных, когда есть 4 или 5 разных уровней персистентности, генерирующих SQL для получения данных? Вы не можете ничего изменить! ORM или любой код, который генерирует SQLзаблокировать вашу базу данных в камне.