Смысл отдельной ORM при LINQ?
От: huligun Россия  
Дата: 11.07.08 17:10
Оценка:
У нас в конторе почти с каждым новым проектом новая ORM. Юзали .netTiers, DataTables и LINQ. По сравнению с LINQ, все остальное для меня теперь лишнее повышение сложности. А как говорит Макконнелл, борьба с ней это главный технический императив Дак вот, очередной проект и наш архитектор решил использовать очередную ORM под названием PLINQO То есть опять же генерация сущностей при любом изменении базы Обоснование использования привел как наличие встроенных функций по типу GetByForeignKey, но ведь в линке это всего пару строчек, там и так отличное обращение ко всем связанным таблицам. Но это было бы еще пол беды Вторая цель введения ORM — изолировать работу с БД. Пользоваться линкой напрямую из кода запрещено, если надо выполнить запрос к бд, то надо создать отдельный метод в менеджере данной таблицы(эта орм генерирует менеджер для каждой таблицы) и уже вызывать его. Для каждого запроса отдельный метод! Встает вопрос как из метода вернуть анонимный тип? В качестве решения выбрали возвращать object, из него поля конечно просто так не вытащишь, но при биндинге работает...

Уважаемые архитекторы, проясните для меня ситуацию, может наш архитектор прав и не стоит использовать линк в коде, а писать для каждой операции отдельный метод?
linq orm plinqo
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.