Рефакторим и переписываем на .NET большой проект. Встаёт дилема/проблема выбора framework-а для работы с данными.
Основная концепция — это разумная автоматизация. Я не хочу делать всё руками, но и не хочу отказываться от стор и написания TSQL кода.
Я для себя набросал некоторые требования к нашему DAL Framework. Может многоуважаемый ALL посоветует какое то готовое решение.
Ну и просто мысли и замечания — велкам. Ответы желательно максимально конкретизировать и избежать обсуждения "сферического коня в вакууме".
DAL Framework должен:
1. Позволять генерировать C# wrapper-ы для
1.1. Вызова хранимых процедур, при этом если хранимая процедура возвращает resultset, то entity класс так же должен быть сгенерирован
1.2. Таблиц/View (CRUD), при этом очень желательно что бы при помощи сгенерированного класса можно было бы обновить как одно или несколько полей, так и все поля
1.3. Custom запросов (не хранимых процедур).
Например мы хотим сделать некоторый select, но нехотим делать хранимую процедуру, при этом мы хотим, что бы entity сгенерировалась DAL Framework-ом автоматически, по полям выборки
1.3. Сгенерированный DAL должен нормально поддерживать транзакционность
Тоесть, должна быть возможность например обновить несколько таблиц и вызвать стору в одной транзакции без использования TransactionScope
Не хочется для одной транзакции использовать несколько соединений с БД, например из за увеличения риска дедлоков
1.4. Сгенерированные entity классы должны легко сериализовываться в XML
1.5. Сгенерированные entity классы должны легко передаваться по WCF
1.6. Сгенерированные entity классы должны быть disconnected от базы
1.7. Чем проще будут сгенерированные entity классы — тем лучше. Естественно, что POCO буде идеалом
1.8. Естественно все сгенерированные классы должны быть Partial
1.9. Гибкое управление (возможность контролировать) сгенерированным C# кодом будет большим плюсом
1.10 Гибкое управление (возможность контролировать) сгенерированным TSQL кодом будет большим плюсом
2. Должна быть возможность генерировать (или обновлять уже существующий) DAL по базе во время билда, а не только из студии или какой либо утилиты
Нужно что бы сгенерированный DAL всегда был бы up to date и иметь compile time проверки
3. В идеале должен быть хорошо поддерживаемым комерческим продуктом, ещё лучше если будут доступны исходники
4. В идеале должен быть заточен, или очень хорошо понимать MS SQL 2005/2008
DAL Framework НЕ должен:
1. Быть полноценным ORM с поддержкой связей, коллекций, многоуровневых внутренних кэшэй и прочей "тяжеловесной" ерунды с которой в будущем придётся бороться
2. Не должен заменять SQL своим языком, или уж если и заменяет то это должна быть полная/полноценная поддержка TSQL 2005/TSQL 2008
Писать велосипед не предлагать
Во флэйм не пускаться
