Является ли Codesmith жизнеспособным инструментом ORM (или мне следует придерживаться настоящего ORM)

Я покупаю ORM-инструмент. Я страдаю покупкой либо CodeSmith (который в настоящее время доступен со значительной скидкой), либо ORM-инструмента.

LINQ to SQL исключен из моего списка; SubSonic 2.x исключен из списка (я не хочу вкладываться в этот тупик, зная, что появится SubSonic 3.0. NHibernate кажется излишним, как и LLBLGEN. Я только кратко оценил EF, но не могу быстро получить ощущение тепла и нечеткости от него.

Неужели я с ума сошел, думая, что CodeSmith - рациональная альтернатива стандартным ORM? Будет ли CodeSmith окупаться другими способами?

Обратите внимание, что я никоим образом не связан с какими-либо поставщиками, и это не дешевый вопрос, ТАК просто ради создания шума от продукта! Мне нужен честный совет и мнение о CodeSmith как об инструменте ORM (с его предоставленными или доступными сообществом) шаблонами.

Ответов (8)

Решение

Фактически, hibernate - хороший инструмент ORM. Но на этом все заканчивается!

Возможности Code smith могут быть больше, чем просто штат реляционного картографирования! Я использую code smith для создания некоторых форм пользовательского интерфейса, бизнес-слоев (шаблонов), слоев доступа к данным, шаблонов и т. Д. Но для работы с code smith вам может потребоваться хороший опыт проектирования систем или использование их шаблонов, которые я не люблю использовать, но мне нравится в качестве примера.

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

Решение тяжелое; Я постоянно читал такие важные имена, как Скотт У. Амблер, Кент Бек, Роберт С. Мартин и людей из серии «Прагматичные программисты», которые рекомендуют ORM Tool для ускорения разработки. Они сказали, что разработчики ORM Tool озабочены всеми проблемами базы данных (пул, соединения, специфика поставщика базы данных и т. Д.). Поэтому, когда нам нужно проектировать уровни доступа к данным, мы также должны учитывать все эти аспекты.

Я считаю, что эти инструменты ORM имеют слишком большую нагрузку. Я еще не знаю, как эти инструменты будут вести себя в малобюджетных проектах (я имею в виду плохие хостинговые серверы или какие-либо общие ресурсы). Я видел, как неопытные разработчики не принимали это во внимание, пытаясь проповедовать свои любимые инструменты. Но в java-проектах hibernate - уже широко распространенный и хорошо известный инструмент. Я не сомневаюсь, что великие проекты были реализованы с использованием этой технологии, но я видел кого-нибудь, и снова разработчикам Java может потребоваться научить нас (разработчиков .net), как создавать отличные решения. (Извините, мы должны признать.)

Единственное, что я бы порекомендовал, - это учитывать ваш контекст. Вы делаете новую систему? Вам нужна работа в выкройке? Вы когда-нибудь пробовали рассматривать такой генератор кода и инструменты ORM вместе?

Я предпочитаю code smith, потому что я генерирую сразу целые решения, а не только уровень доступа к данным. Генерация кода очень важна, и не в последнюю очередь Microsoft имитировала подход кузнеца кода в visual studio.net 2008 и так далее.

Удачи

Несколько лет назад я использовал LLblgen. Надеюсь, увиденное было исправлено. Мы посмотрели на созданный встроенный SQL и увидели, что для выбора одной строки данных с переданным первичным ключом:

SELECT DISTINCT * FROM TABLE WHERE primark_key_id = @primarykey.

В самом деле, ОТЛИЧИТЕЛЬНЫЙ? Я всегда умолял сделать вместо них store procs, но то, что сбил руководитель проекта. Я не уверен, сколько времени было сэкономлено за счет написания неэффективного кода.

Code Smith - это не ORM, это просто IDE генератора кода.

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

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

И затем вы должны подумать о том, что происходит, когда вы вносите изменения в свою базу данных, вам, скорее всего, придется запускать code smith и строить каждый раз, когда вы это делаете. Хорошая ORM позволит вам настроить изменения вашей базы данных в схеме, а затем она будет генерироваться динамически, поэтому вам не придется беспокоиться (так сильно) о внесении изменений в базу данных.

Я считаю, что использование Codesmith жизнеспособно. Но вам следует изучить фреймворки, которые его используют. Net Tiers - это платформа приложений, на которой можно создать хороший DAL.

NHibernate - это то, что вам нужно. Это ORM корпоративного уровня. А с автоконфигурацией на основе соглашений из библиотеки FluentNHibernate настройка до смешного проста, если вы придерживаетесь одного соглашения (вы можете указать соглашения или есть значения по умолчанию).

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

Почему что-то вроде LLblgen будет лишним? Мы используем его на работе, и после довольно крутого обучения это очень приятно :). Вы должны хотя бы попробовать это и попробовать nhibernate.

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

Я использую netTiers ежедневно, и мне это нравится. Документация для него отстой, но я так сэкономил время в офисе. Многие люди недовольны объемом кода, который он производит, но, судя по тому, что я видел, код, который он создает, намного быстрее, чем ручное кодирование большей части. Он также генерирует все sprocs, которые вам понадобятся для ваших основных материалов CRUD. Методы доступа, которые он производит, также довольно хороши, поскольку они обрабатываются всеми вашими уникальными ключами, внешними ключами и первичными ключами.

Используйте netTiers и .netMVP. NetTiers - это очень хороший DAL, а .netMVP - это платформа, которую я только что выпустил для поддержки абстракции на уровне пользовательского интерфейса. :)

http://community.codesmithtools.com/CodeSmith/m/templates/42499.aspx