Сообщение Re[4]: А как сейчас модно работать с БД из-под Windows? от 15.09.2015 14:55
Изменено 15.09.2015 15:05 AlexGin
Здравствуйте, IT, Вы писали:
IT>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.
То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.
IT>Ну вот, опять началось
У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?
Некоторое представление есть. В кода проекта моего приложения на C# — пишу SQL-подобное.
Хотя, в том же приложении, я могу написать строковый SQL-запрос (как обычно и делаю).
ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Риторический вопрос — что мне даст LINQ
IT>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов.
В смысле — работа с XML, как с объектами БД? Я верно понял?
IT>linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?)
Я не придерживаюсь той точки зрения, что хранимые процедуры полезны. Лично я не пользуюсь хранимками ими уже почти 10 лет.
Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?
IT>linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
ИМХО всё это объединяет исполнимый код с кодом SQL-запроса. Не буду уповать на философию.
Ключевой вопрос — как все это отлаживать???
IT>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.
То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.
IT>Ну вот, опять началось
У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?Некоторое представление есть. В кода проекта моего приложения на C# — пишу SQL-подобное.
Хотя, в том же приложении, я могу написать строковый SQL-запрос (как обычно и делаю).
ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Риторический вопрос — что мне даст LINQ
IT>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов.
В смысле — работа с XML, как с объектами БД? Я верно понял?
IT>linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?)
Я не придерживаюсь той точки зрения, что хранимые процедуры полезны. Лично я не пользуюсь хранимками ими уже почти 10 лет.
Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?
IT>linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
ИМХО всё это объединяет исполнимый код с кодом SQL-запроса. Не буду уповать на философию.
Ключевой вопрос — как все это отлаживать???
Re[4]: А как сейчас модно работать с БД из-под Windows?
Здравствуйте, IT, Вы писали:
IT>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.
То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.
IT>Ну вот, опять началось У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?
Некоторое представление есть. В кода проекта моего приложения на C# — пишу SQL-подобное.
Хотя, в том же приложении, я могу написать строковый SQL-запрос (как обычно и делаю).
ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Риторический вопрос — что мне даст LINQ
IT>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов.
В смысле — работа с XML, как с объектами БД? Я верно понял?
IT>linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?)
Я не придерживаюсь той точки зрения, что хранимые процедуры полезны. Лично я не пользуюсь хранимками — уже почти 10 лет.
Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?
IT>linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
ИМХО всё это объединяет исполнимый код с кодом SQL-запроса. Не буду уповать на философию.
Ключевой вопрос — как все это отлаживать???
IT>Это провайдер использовался одно время в BLToolkit, но не прижился. Всё современные БД уже имеют вполне зрелые нативные .net провайдеры, поэтому в ODBC необходимость отпадает. К тому же, ODBC нужно дополнительнос ставить, а для большинства провайдеров этого не нужно.
Да, нужно дополнительно ставить, но после этого у пользователя появляетюся возможности управления ODBC — data source (даже в плане оперативного тестирования канала связи с источником данных); кроме того — ODBC обладает универсальностью.
То есть — возможности применения этого самого data source НЕ ТОЛЬКО в приложениях на .NET, но и приложениях на C++ например.
IT>Ну вот, опять началось
У меня сразу вопрос, у тебя есть хотя бы общее представление о LINQ?Некоторое представление есть. В кода проекта моего приложения на C# — пишу SQL-подобное.
Хотя, в том же приложении, я могу написать строковый SQL-запрос (как обычно и делаю).
ИМХО, строковый натуральный SQL-запрос я могу отладить в MS SQL Server Management Studio, в отличие от LINQ.
Там же (в MS SQL Server Management Studio) — можно поиграть с запросом, видоизменить его или оптимизировать.
Риторический вопрос — что мне даст LINQ
IT>LINQ в принципе нельзя сравнивать с вещами типа ODBC. LINQ может работать поверх ODBC, ADO.NET, XML или просто объектов.
В смысле — работа с XML, как с объектами БД? Я верно понял?
IT>linq2db, linq2sql, EF и прочие — это LINQ провайдеры для баз данных. Каждый со своими достоинствами и недостатками. Например, философия (где там Олег К.?)
Я не придерживаюсь той точки зрения, что хранимые процедуры полезны. Лично я не пользуюсь хранимками — уже почти 10 лет.
Тем не менее, вполне пишу текстовые SQL-запросы в кодах (будто C#, или C++). Отлаживаю — в студии серверя. ЧЯДНТ?
IT>linq2db — это типизированный SQL интегрированный в C#. Филисофия EF (от которой постепенно отходят) — это жирный ORM, всемогутор, симулятор персистентности объектной модели приложения и поставщик прочих entity services. linq2sql — удачная проверка концепции, загубленная теми, кому эта технология в дальнейшем была отдана для поддержки и продвижения.
ИМХО всё это объединяет исполнимый код с кодом SQL-запроса. Не буду уповать на философию.
Ключевой вопрос — как все это отлаживать???