Прямая запись в справочник 1C: Предприятие через Linq на примере работы с пользователями Asp.Net

[lair]

Судя по dbml-файлу, это, на самом деле, Linq2Sql, так? Или все-таки какой-то собственный провайдер?

А теперь скажите мне, в чем смысл? С точки зрения дизайна приложения приведенные вами примеры очень плохи. С точки зрения технологии ничего особо нового они тоже не представляют — обычная интеграция через базу данных, имя которым легион (и которые уже давно перестали быть рекомендуемым подходом). Так зачем?

[Elisy]

В основу положена технология LinqToSql, а не собственный провайдер.
Не совсем понятно, в чем «плохость» примера. В статье показан именно такой способ доступа. Все понимают, что у любого подхода есть как достоинства, так и недостатки. В некоторых случаях прямой доступ к 1С оправдан, в других – нет.
В том, что особо нового ничего нет — не соглашусь. Статья показывает, как можно получать и обновлять данные в 1С напрямую. Раньше был достаточно хорошо исследован способ только по получению данных. Возможность вменяемого обновления – это новизна.
Смысл подхода — хранить все данные централизованно в 1С без экспорта/импорта в сторонние CMS, экономить время на создании административного интерфейса, экономить на MSSQL, размещенном удаленно у провайдера.

[lair]

Не совсем понятно, в чем «плохость» примера.

В нарушении принятых «хороших» практик программирования (например, Dependency Inversion). Ваш код тестируем?

Статья показывает, как можно получать и обновлять данные в 1С напрямую.

Не показывает. Статья показывает, как обновлять данные в Linq2Sql-датаконтексте, и это, извините, не новость вообще. А вот как устроен Linq2Sql-датаконтекст, что он может работать с БД 1С мы как раз и не видим, так что работа с 1С никак не показана.

[Elisy]

Мой код тестируем, не понятна причина сомнений в тестируемости. То, что подход не попадает под какие-то практики программирования я допускаю, но я также допускаю, что он попадает под другие практики программирования. Думаю, практики – это не очень хороший критерий оценки, потому что субъективны, они могут меняться со временем на противоположные. Давайте оперировать более измеряемыми величинами: временем и деньгами, а философию оставим для других статей и разделов. Подход дает экономию времени, и стоимости. И если вы придете к клиенту и скажете есть решение, позволяющее сэкономить, но нарушающее практику «Dependency Inversion», думаю, что с нарушением этой практики клиент смирится. Интересно, кстати, было бы посмотреть, как вы клиенту будете объяснять, почему он должен доплачивать за точное соблюдение этой практики )))).

То, что все умеют обновлять данные в Linq2Sql – это не новость, но новость заключается в том, что обновление идет данных 1С, которая славится запутанностью своей структуры. И без статьи это обновление займет значительно больше времени, пока вы разберетесь с названиями таблиц и полей.

[lair]

Мой код тестируем, не понятна причина сомнений в тестируемости.

Причина очень проста: как вы будете тестировать, скажем, класс AccountMembershipService (не обращаясь к БД, конечно же)?

Давайте оперировать более измеряемыми величинами: временем и деньгами, а философию оставим для других статей и разделов.

Конечно же, давайте. Только давайте мы будем считать время и деньги не только разработки, но и поддержки, и внесения изменений.

Интересно, кстати, было бы посмотреть, как вы клиенту будете объяснять, почему он должен доплачивать за точное соблюдение этой практики

Такие вещи не объясняются клиенту. Такие вещи объясняются руководителю проекта и вносятся в технические расходы.

И без статьи это обновление займет значительно больше времени, пока вы разберетесь с названиями таблиц и полей.

Статья не объясняет, как это происходит. Статья говорит «возьмите утилиту и получите код». Как он работает — не описано.

[Elisy]

Причина очень проста: как вы будете тестировать, скажем, класс AccountMembershipService (не обращаясь к БД, конечно же)?

Структура классов и методов один в один взята из стандартного проекта Asp.Net MVC 3 из Visual Studio 2010, чтобы разработчики, знакомые с Asp.Net MVC нашли знакомые точки соприкосновения. Поэтому вопрос тестирования конкретного класса AccountMembershipService лучше адресовать не ко мне, а к Microsoft. Если не ошибаюсь, проект Asp.Net MVC в Visual Studio можно создать с включенными классами тестов и ознакомиться с тем, как Microsoft предлагает решить эту проблему. Если кому-то не понравится структура классов, он может сделать свою, это никак не повлияет на описанный метод.

Конечно же, давайте. Только давайте мы будем считать время и деньги не только разработки, но и поддержки, и внесения изменений.

Предложите альтернативный подход для сравнения, подходящий под ваши критерии и практики. Будем сравнивать конкретные вещи, а не просто данный подход с неизвестным идеальным.

Такие вещи не объясняются клиенту. Такие вещи объясняются руководителю проекта и вносятся в технические расходы.

Если вы внесете эти расходы в технические расходы и клиент согласится, то речь идет о том получит ли ваша компания прибыль в размере сэкономленных денег и времени или нет. Тоже самое, но вид сбоку.

Статья не объясняет, как это происходит. Статья говорит «возьмите утилиту и получите код». Как он работает — не описано.

Вы противоречите себе. С одной стороны вы не находите ничего нового в технологии LinqToSql, но требуете досконального описания этой технологии. Код, получаемый в результате работы утилиты ничем не отличается от стандартного кода для доступа к обычным MSSQL таблицам, получаемым на основе dbml-файлов в Visual Studio. Заслуга утилиты — найти соответствие между человекочитаемыми названиями и непонятными названиями таблиц и полей.

[lair]

Поэтому вопрос тестирования конкретного класса AccountMembershipService лучше адресовать не ко мне, а к Microsoft.

Ну то есть вы не знаете, как. В этом и претензия — ваш код не пригоден для автоматического тестирования, поздравляю.

Предложите альтернативный подход для сравнения, подходящий под ваши критерии и практики. Будем сравнивать конкретные вещи, а не просто данный подход с неизвестным идеальным.

IoC во главе угла.

Заслуга утилиты — найти соответствие между человекочитаемыми названиями и непонятными названиями таблиц и полей.

Вот как она это делает — и надо описывать. Все остальное — скучно и не ново.

[Elisy]

Ну то есть вы не знаете, как. В этом и претензия — ваш код не пригоден для автоматического тестирования, поздравляю.

Я не задавался целью охватить тестами весь код. То, что код не пригоден для автоматического тестирования — голословное обвинение. На любой алгоритм статьи можно написать код проверки, зная, какой результат ожидается от этого метода.

IoC во главе угла.

Для конструктивного диалога нужно сравнивать сравнимые вещи. Не можем же мы сравнивать ваш лозунг из 3х букв и методику из статьи, приводящую к конкретному результату.

Вот как она это делает — и надо описывать. Все остальное — скучно и не ново.

Да ну?! То есть более-менее вменяемые методы прямой записи в базу 1С всем давно известны?

[lair]

Я не задавался целью охватить тестами весь код.

Прекрасно. А сколько из вашего (приведенного в статье) кода охвачено тестами?

То, что код не пригоден для автоматического тестирования — голословное обвинение.

Ну, оно вполне доказуемо. Единственное, что изначально я говорил о тестируемости кода, и имел в виду изолированное тестирование.

Для конструктивного диалога нужно сравнивать сравнимые вещи. Не можем же мы сравнивать ваш лозунг из 3х букв и методику из статьи, приводящую к конкретному результату.

А это как раз очень легко сравнимые вещи. Прямо в числовом выражении. В вашей статье, если я не ошибаюсь, описано семь методов. Сколько из них можно покрыть юнит-тестами при условии сохранения используемого в статье подхода управления зависимости, и сколько — при использовании IoC?

То есть более-менее вменяемые методы прямой записи в базу 1С всем давно известны?

Вы же сам писали «Код, получаемый в результате работы утилиты ничем не отличается от стандартного кода для доступа к обычным MSSQL таблицам». Следовательно, метод прямой записи в базу 1С — это стандартная работа с БД MSSQL (о чем, снова, пишете вы сам: «В основу положена технология LinqToSql»). Степень вменяемости этого метода ограничена степенью вменяемости Linq2Sql, которую мы тут обсуждать не будем.

[Elisy]

Прекрасно. А сколько из вашего (приведенного в статье) кода охвачено тестами?

Охвачено тестами ровно столько кода, сколько охвачено кода тестами при создании нового проекта Asp.Net MVC. Конкретное значение 20 или 80% что-то изменит? Демагогией не надоело заниматься?

А это как раз очень легко сравнимые вещи. Прямо в числовом выражении. В вашей статье, если я не ошибаюсь, описано семь методов. Сколько из них можно покрыть юнит-тестами при условии сохранения используемого в статье подхода управления зависимости, и сколько — при использовании IoC?

Если не надоело заниматься демагогией — продолжним. Жду от вас статьи, оформленной по всем хорошим общепринятым практикам программирования, с учетом IoC, покрытую 100% тестами, в т.ч. изолированными, решающую схожую проблему: прямая регистрация пользователей в базе 1С и авторизация. Дальше продолжим сравнение моего и вашего подходов не на пальцах. Вам отправить архив MSSQL или 1С?

[lair]

Конкретное значение 20 или 80% что-то изменит?

Конечно, изменит.

Жду от вас статьи, оформленной по всем хорошим общепринятым практикам программирования, с учетом IoC, покрытую 100% тестами, в т.ч. изолированными, решающую схожую проблему: прямая регистрация пользователей в базе 1С и авторизация.

Я правильно понимаю, что вы не можете ответить на озвученный мной вопрос в отношении вашего кода?

[Elisy]

Я правильно понимаю, что вы не можете ответить на озвученный мной вопрос в отношении вашего кода?

Ответ на данный вопрос: «Сколько из них можно покрыть юнит-тестами при условии сохранения используемого в статье подхода управления зависимости, и сколько — при использовании IoC?» мы сможем получить после прочтения вашей статьи. Ведь каждый может вкладывать свой смысл в аббревиатуры. Я, например, в преддверии Олимпиады расшифровываю ее как International Olimpyc Committee, а вы, вероятно, имеете ввиду что-то другое. Ситуацию прояснит ваш код, оформленный по общепринятым (непонятно кем) хорошим (непонятно почему) принципам программирования. Но сильно не переусердствуйте, потому что тема тестирования, если ей уделять много внимания, запутает благодарного читателя, и он может не понять суть решаемой проблемы. Ведь мы же не пишем статьи про тестирование, а нацелены на разработку.

[lair]

Ответ на данный вопрос: «Сколько из них можно покрыть юнит-тестами при условии сохранения используемого в статье подхода управления зависимости, и сколько — при использовании IoC?» мы сможем получить после прочтения вашей статьи.

Это не один вопрос, а два. И на половину из него (сколько из них можно покрыть юнит-тестами при условии сохранения используемого в статье подхода управления зависимостями) вы можете ответить прямо сейчас… если, конечно, вы задумывались о тестируемости вашего кода.

Я, например, в преддверии Олимпиады расшифровываю ее как International Olimpyc Committee, а вы, вероятно, имеете ввиду что-то другое.

Я, несомненно, имею в виду что-то другое. То, что принято иметь в виду под аббревиатурой IoC на сайте, связанном с программированием.

Ведь мы же не пишем статьи про тестирование, а нацелены на разработку.

Во-первых, вы путаете тестирование и тестируемость. А во-вторых тестирование — неотъемлимая часть процесса разработки, так что его обязательно необходимо принимать во внимание.

[foxmuldercp]

Я Вас огорчу — при включении тестов при создании mvc3/4/5 в VS12/13 Вы получаете три суперсложных трёхстрочных заглушечных теста на ненулевой возврат контента про вызове методов Index, About, Contacts контроллера Home, не говорящих ни о чём.
Кстати, если кто поделится хорошей литературой по msunit'у, в том числе авторизацию в веб, буду благодарен.

[lair]

Кстати, если кто поделится хорошей литературой по msunit'у, в том числе авторизацию в веб, буду благодарен.

А вам о чем конкретно? Потому что тестирование авторизации в веб слабо зависит от того, каким тестовым фреймворком вы пользуетесь, подходы идентичны (и обычно описываются в книге по фреймворку, например, в книжке по WebAPI немаленький такой раздел про то, как это тестировать).

[foxmuldercp]

мне — вообще о MS Unit — сам пишу на Wpf/Winforms/MVC но если пишу с горем пополам, то написать тест сложнее штатных — не зщнаю куда копат, к ниг по ms unit'у толи не нахожу толи в гугле забанили. хочется почитать при тестирование как десктоп так и веб приложений, но у меня веб приложение совсем нав авторизацию закрыто, поэтому надо и авторизацию во всех методах дописывать, на этом затык, а без тестов уже сложно контролировать что могло отвалиться при очередных правках.

[lair]

Судя по тому, что вы пишете, вам надо начинать с самых азов. Повторюсь еще раз, бессмысленно читать о конкретном тестовом фреймворке, идеология у всех одинаковая. Читать надо о тестировании (чтобы не было ошибочных допущений «надо и авторизацию во всех методах дописывать») вообще. Я бы посоветовал The Art of Unit Testing и xUnit Test Patterns.

[Elisy]

Спасибо, что проинформировали. Может еще просветите, какие затруднения вызовет написание тестов для методов, описанных в статье? Хоть убейте меня, не могу понять — если есть метод, известно, чем он занимается, что на входе, а что на выходе — почему нельзя проверить правильно ли он сработал или нет.

[Fragster]

1С движется в сторону облегчения интеграции. В 8.3.5 должны появиться плюшки для еще более простой интеграции, назвали REST, но учитывая определенную размытость формулировки, я лучше приведу ссылки:

v8.1c.ru/o7/201312rest/index.htm
v8.1c.ru/o7/201312http/index.htm