Предыстория: Привет всем, я просто потратил много времени, читая многие темы LINQ vs Nhibernate здесь и на других сайтах. Я работаю в небольшой команде разработчиков из 4 человек, и у нас даже нет супер опытных разработчиков. Мы работаем на небольшую компанию, у которой много технических потребностей, но недостаточно разработчиков для их реализации (и больше о найме не может быть и речи).
Как правило, наши проекты (которые по отдельности довольно малы) были написаны отдельно и в любом случае не были на самом деле многоуровневыми, код не использовался повторно, нет библиотек классов, и мы просто используем файлы LINQtoSQL .dbml для наших объектов. мы на самом деле даже не используем объекты, но передаем значения и прочее, единственный раз, когда мы используем объекты - это при вставке в базу данных (черт возьми, даже не запрашивая, так как вам не нужно присваивать его типу, а можно просто привязать к вид сетки). Несмотря на все это, как я уже сказал, у нашей компании много технических потребностей, никто не может прийти к нам в течение года, и у нас будет много работы для реализации запрошенных функций.
Ну, я решил сначала немного это изменить, создав библиотеки классов и фактически добавив слои в наши приложения. Существует большая возможность сделать несколько хороших приложений с всеобъемлющей функциональностью. Я пытаюсь встретиться с этими парнями на полпути, все еще используя LINQtoSQL в качестве ORM, и все еще использую VB в качестве языка. Тем не менее, я нахожу, что в течение многих дней в LINQtoSQL было так много всего, что мне было легко в Nhibernate (автоматическая обработка сеанса, создание критериев проще, чем деревьев выражений, обобщение динамических запросов и т. Д.) Итак. ..
Вопрос: Как я могу убедить моих ведущих разработчиков и других старших программистов, что переход на Nhibernate - это хорошо? Что контролировать наши доменные объекты - это хорошо? Способность реализовывать интерфейсы - это хорошо? Я пытался объяснить преимущества этого прежде, но они не поняли его, потому что они никогда не программировали в истинном OO и многоуровневом способе.
Также один из встречных аргументов, который я вижу, - sqlMetal генерирует эти классы автоматически и, следовательно, экономит много времени. Я не могу противостоять этому, кроме как сказать, что тратить больше времени на инфраструктуру, чтобы сделать ее более масштабируемой и гибкой, - это хорошо, но они не понимают, как.
Опять же, я знаю особенности и преимущества (в некоторой степени, я считаю) каждого из них, но мне нужны аргументы, применимые к моему контексту, поэтому я и предоставил предысторию. Думаю, я не очень хороший спорщик.
(Предостережение: для всех любителей LINQtoSQL я, возможно, просто не настолько опытен, как LINQ, но я нахожу весьма обременительным тот факт, что вам необходимо загрузить дополнительную библиотеку для динамических запросов, которые по умолчанию не поддерживают сравнения guid, и я также нахожу способ обновления прав достаточно громоздким и с точки зрения управления контекстом данных, так что я могу просто сосать хе-хе.)