Здравствуйте, Олег К., Вы писали:
IT>>На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса
ОК>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
Подозреваю, если для решения некоторой конкретной задачи программирование в процедурном стиле (в стиле Си, как ты пишешь) без инкапсуляции, приватных методов и свойств позволит создать более компактный, выразительный, легко читаемый, тестируемый и поддерживаемый код, то Игорь без колебаний махнет рукой на все фенечки ООП. Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?
Другой вопрос — даст ли переход на Си-стиль какой-нибудь профит?
А вот отказ от DAL, очевидно дает.

Вообще, всякие паттерны, ООП, вирутальности, инкапсуляции, слоистую структуру, ORM-ы, сервисы и пр, и пр, и пр. придумали для того, чтобы сделать код проще для написания, понимания и рефакторинга. Иными словами все выше перечисленное — не есть самоцель, а лишь инструменты. Цель — достижение простоты и выразительности. Вернее снижение сложности в одном аспекте за счет неизбежного повышения сложности с другом аспекте (у Игоря на этот счет есть замечательная, кстати, вполне философская статья

Автор(ы): Игорь Ткачёв
Дата: 06.12.2002

).
Если инструмент подходит для достижения цели, его используют, если не подходит — его не используют.

Когда-то, тот же IT, если не ошибаюсь, писал (ссылку уже не найду), что иметь слой DAL в программе — это так же считается хорошим тоном как чистить зубы по утрам и вечерам. Но если зубов нет, то и чистить, в общем-то, ничего не надо. Иными словами, задача слоя DAL в одном месте локализовать функционал преобразования нетепизированных объектов БД в строго типизированные объекты языка программирования (C# например) и наоборот. Если проблемы с этим преобразованием нет (а LINQ эту проблему снимает), то проблема, которую призван решить DAL, исчезает. Соответственно, становится не нужным и сам DAL.

Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.

Здравствуйте, Олег К., Вы писали:
IT>>На философию мне положить большой болт. Это самое последнее о чём нужно думать. Есть более важные вещи, такие как поддержка кода и организация рабочего процесса
ОК>Ну так ты начни писать еще в стиле Си — откажись от функций членов и сделай все переменные члены публичными. Тебе ж положить на философию большой болт.
Подозреваю, если для решения некоторой конкретной задачи программирование в процедурном стиле (в стиле Си, как ты пишешь) без инкапсуляции, приватных методов и свойств позволит создать более компактный, выразительный, легко читаемый, тестируемый и поддерживаемый код, то Игорь без колебаний махнет рукой на все фенечки ООП. Для HelloWord или вычисления корней квадратного уравнения ты же станешь приватные методы писать правда (я утрирую конечно)?
Другой вопрос — даст ли переход на Си-стиль какой-нибудь профит?
А вот от отказа от DAL Игорь, очевидно, профит получает.

Вообще, всякие паттерны, ООП, вирутальности, инкапсуляции, слоистую структуру, ORM-ы, сервисы и пр, и пр, и пр. придумали для того, чтобы сделать код проще для написания, понимания и рефакторинга. Иными словами все выше перечисленное — не есть самоцель, а лишь инструменты. Цель — достижение простоты и выразительности. Вернее снижение сложности в одном аспекте за счет неизбежного повышения сложности с другом аспекте (у Игоря на этот счет есть замечательная, кстати, вполне философская статья

Автор(ы): Игорь Ткачёв
Дата: 06.12.2002

).
Если инструмент подходит для достижения цели, его используют, если не подходит — его не используют.

Когда-то, тот же IT, если не ошибаюсь, писал (ссылку уже не найду), что иметь слой DAL в программе — это так же считается хорошим тоном как чистить зубы по утрам и вечерам. Но если зубов нет, то и чистить, в общем-то, ничего не надо. Иными словами, задача слоя DAL в одном месте локализовать функционал преобразования нетепизированных объектов БД в строго типизированные объекты языка программирования (C# например) и наоборот. Если проблемы с этим преобразованием нет (а LINQ эту проблему снимает), то проблема, которую призван решить DAL, исчезает. Соответственно, становится не нужным и сам DAL.

Твой же пуристический подход предполагает следование догмам независимо от того нужны ли они и продуктивны ли.