Зачем нам нужны объекты сущностей? [закрыто]

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

Меня очень интересует масштабируемость. Объекты Entity никогда не мешают создавать хорошо масштабируемое приложение, но вы должны делать это правильно, другими словами, вам нужен рукописный DAL, а не DAL, сгенерированный с использованием некоторого ORM. На самом деле, именно поэтому мне не нравятся ORM, ничто не может сравниться с написанным от руки DAL, я также не использую LINQ, так как во многих местах я читаю, что у него большие накладные расходы. Я настраиваю каждый запрос в своих приложениях и создаю необходимые индексы, я не позволяю некоторому ORM генерировать для меня код.

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

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

Я озадачен о "блокировке Ваша база данных в камне" аргумент в пользу сохраненного procs. Я могу взять свою модель ActiveRecord и переместить ее от MySQL до Пост-ГРЭС к SQLite, большое спасибо. Я не мог сделать, это с чем-либо сохранило находящийся в proc, если я не хотел переписать их всех.

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

Мой опыт с stored-proc-based системами минимален все же. Мне любопытно в крупных приложениях, как Вы управляете всеми отношениями данных? На одной странице я показываю продукт с изображением. На другой странице я показываю продукт и пользователя, который создал ее. На другой странице я показываю продукт и комментарии об этом. На другой странице я должен показать что продукт без изображения, к которому присоединяются с таблицей спецификаций об этом.... и т.д. и т.д. У меня есть модель данных с большим количеством отношений. Я предполагаю, что Вы не пишете сохраненный proc для каждой комбинации? Принцип DRY является тем, о котором я волнуюсь. Сколько запросов я пишу, где я - re-left-joining (эффективно повторно кодирующий) мои отношения? И, в то время как мы говорим о блокировке схемы, в каком количестве сохраненного procs я испытываю необходимость для переписывания?

Я размышлял, не являются ли реляционные базы данных, управляемые SQL, немного в противоположных намерениях с этими платформами, которые используют парадигму ActiveRecord. Одна фундаментальная проблема состоит в том, что AR (и хороший дизайн OO, в этом отношении), управляйте нами для разложения логики; и SQL просто не поддается разложению оператора.

Интересно, если использование isam модели персистентности для базы данных не было бы лучшей идеей; лучшая подобранность импедансов к OO; больше соглашения по основной идее о данных как таблицы; более согласовывающийся со стандартными артефактами персистентности OO. Один хороший пример - то, что FKs и их ассоциации могут быть более явными.

RoR имеет представителя того, чтобы быть кратким заголовком базы данных, и я подозреваю, что этой проблемой является значительная часть причины.

Кто-либо попытался использовать isam базу данных для реализации ActiveRecord?

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

Я не прочитал все ответы, но общие моменты стали липкими:

• Код повторяется Багги, нестабильный код
• ОГРОМНЫЕ классы, загруженные статическими
  классы
• Логика везде и
  где угодно (aspx, статические методы, sql, триггеры)
• Взаимодействие с несколькими
  объекты, разделяющие общие черты, Доказать сложно

Что касается домена против данных. Я думаю, что данные будут всегда побеждать, функциональность - это ВСЕ, что важно для клиента. Это должно работать. Я сторонник рефакторинга, когда вы можете, если вы нарушаете принцип доставки чего-то, что работает вовремя ... вы всегда можете вернуться и рефакторинг.

Также небольшое слово об отладчике, сложной области. Мне кажется, многие напуганы, потому что бьют по интерфейсам, не понимают всей акробатики, которая возможна в очень продвинутом ООП / полиморфном коде. Я ПОЛНОСТЬЮ понимаю, иногда можно потеряться и сдерживаться. Вот почему они создают инструменты. Я меньше боюсь решения с 1000 файлами, чем огромного метода с 1000 строками. И я видел, как оба верят этому или нет.

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

Что ж, хочу поблагодарить вас за увлекательное обсуждение. Я прохожу свой путь через ASP.NET MVC Framework Unleashed Стивена Вальтера, и мне это нравится как своего рода философское упражнение, но я несколько ошеломлен количеством кода, который требует его подход. Это не является неотъемлемой частью использования ORM - Rails гордится тем, что освобождает вас от таких домашних дел, но я действительно борюсь с тем, стоит ли писать и поддерживать отдельный класс Record, который может использоваться приложение и класс EntityRecord, который сопоставляет класс Record с базой данных.

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

Второе упомянутое преимущество состоит в том, что вы можете взять свое приложение и запустить его в другой базе данных. Да, хорошо, может быть, если вы пишете что-то вроде SalesForce для перепродажи или чего-то в этом роде, это может быть целью, но для 90% или более приложений, ну и что? Я вспоминаю соседа из «Это прекрасная жизнь», который дал Джорджу банку денег и сказал: «Я копил это на развод на случай, если у меня когда-нибудь появится муж». Не пишите, пока он вам не понадобится.

С другой стороны, У меня есть практическое возражение против хранимых процедур. Это не обязательно присуще их использованию, но скорее характерно для некоторых из тех, в которых я работал с мертвыми мозгами: они иногда вставляют администраторов баз данных в код, который я хочу написать. Мне нравится думать, что я не ковбой, но, с другой стороны, мне не нравится созывать комитет ООН для добавления поля в таблицу.

Один вопрос: что, если бы вашим источником данных была веб-служба? Я пишу приложения, используя только распределенные данные через веб-службы. Ожидается ли, что я напишу это, используя другую парадигму, чем если бы моим источником данных была СУБД?

Я не спрашиваю, что вы будете делать, если переключитесь с СУБД на веб-службы (потому что во внутреннем магазине это маловероятно) , Я спрашиваю, что вы делаете, когда данные изначально поступают из веб-служб?

Ваша модель программирования кардинально отличается от модели РСУБД? Если это так, нужно учитывать ремонтопригодность. Моим разработчикам было бы ужасно, если бы каждое приложение, в которое они переходили, было запрограммировано с использованием разных парадигм.

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

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

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