Здравствуйте, Artem Korneev, Вы писали:
На днях я начал писать проект. В проекте есть база MSSQL. Entity Framework не использую, потому что у меня есть некий негативный опыт разбирательства с ним, при попытке подключить его к Постгресу.
По итогам прочтения всех страниц холивара
Entity Framework за! и против!Автор: Ringin
Дата: 31.10.12
решил, что если уж знаний SQL у меня достаточно для написания развесистых хранимок для Постгреса, то тяжелый ORM мне не нужен. Использую linq2db, базу пишу руками, хотя — code first для linq2db не помешал бы. Пока все хорошо. Единственное, я не смог заставить работать шаблон linqdb для генерации модели по базе, что-то ему там с путями в шаблоне не нравится. Таким образом, маппинг тоже пишу руками, благо — база еще маленькая.
Преимущество хранимок вижу в том, что обновление логики в хранимке — один запуск скрипта в консоли БД. Обновление атомарное, вступает в действие моментально. Как сделать подобное же обновление в сервере приложений, не обновляя все приложение и не перезапуская его — пока не знаю.
Также, при работе приложений с базой, в двухзвенке в чем-то упрощается их взаимодействие. Сайт на PHP пишет в базу, десктопное приложение на Delphi читает из базы, сервис на Яве работает с этой же базой. Если делать некую прослойку, и засовывать логику в нее, а не в базу, то придется в этой же прослойке решать:
1) Как передавать данные. В прямом смысле — как. Также база может рассылать обновления сама, в постгресе это listen-notify, подобный механизм нужно будет реализовывать в приложении, изобретать протокол или использовать готовый (какой? чтобы его и php понимал, и ява, и дестктопное приложение c#, которым заменят приложение на Delphi)
2) Как делать разделение доступа и логины-пароли. В базе это все есть. Можно даже row-level security сделать.
3) Что делать с обновлением уже изменившихся данных. В базе это просто поле timestamp, соответственно пишем update... where... and ts = :stamp. Следует ли тянуть таймштампы на уровень приложения и отдавать их клиентам, или надо изобретать что-то еще?
В общем, надо писать, а потом еще и писать, и еще писать. То, что в коде СУБД уже давно написано.
