Программные надстройки
В любом автомобиле есть двигатель, колёса, трансмиссия и т.д. Этот набор позволяет назвать устройство автомобилем. Он же позволяет делать с его помощью то что делают с помощью автомобиля, т.е перемещаться из точки А в точку Б.
Точно также любой набор данных в компьютере это всегда массив, т.е последовательность ячеек информации, созданных функцией malloc (язык Си без плюсов). Не важно, откуда и как туда засунута информация, из текстового файл (DBF-текстовый файл) или из файла базы данных вытащено SQL строкой. Важно, что в оперативной памяти (оперативная память – обязательная часть компьютера, так же как а автомобиле обязателен, например, аккумулятор) зарезервировали память с какого-то адреса, столько то байт и что-то туда записали. Что бы и как ни писали в итоге на низком (аппаратном) уровне делается именно это.
Точно также, кто бы и что ни пытался придумывать для Интернета оно будет получать на входе какой-то написанный программистом текст, а на выходе ему придётся сгенерировать и передать браузеру HTML-страницу. Просто потому что это единственный формат информации, понятный Интернет – браузерам.
В микросхему Arduino можно засовывать откомпилированный текст Си или ассемблера. После компиляции получатся коды, понятные микросхеме. На Си обычно писать проще и удобнее, а микросхема понимает только коды также как браузер понимает только HTML.
Когда я писала что метод программирования похож на то, как писали в Borland C++, а имела в виду настройку программной среды, что чем-то похоже на расположение кнопок бортового компьютера. Кнопки можно расставить по-разному, на конечный результат, т.е на то что внутри двигателя при езде будет взрываться топливо и машина будет ехать, это никак не влияет.
Все программные средства это надстройки над ассемблером (не шутка). Вопрос только в том кому удалось придумать более удобное расположение этих самых «кнопок», с помощью которых можно управлять тем, что происходит в компьютере.
Чтобы было удобно, много чего надо. Надо чтобы часто выполняемые операции можно было сделать с минимальными усилиями. Надо чтобы можно было угадать как сделать то, что неизвестно как делать. Программные оболочки тоже могут быть более или менее интуитивные. Если там понятная и естественная логика, то иногда можно обойтись и без описаний. Надо чтобы машина сама что-то делала, но для этого надо чтобы и она правильно «угадывала» какой текст она сама должна написать.
Проблему SQL-строк решили двумя разными способами. Писать и проблеме не очень правильно. Можно говорить о специфике, которая есть в любой профессии и к которой обычно привыкают. Но видимо вопрос «А нельзя ли это как-то упростить?» периодически задавался разработчикам программных средств.
1С –овцы его решили роскошным конструктором запросов, вызываемым прямо из текстового редактора. Их конструктор не имеет ничего общего с MS-овским. Он лучше и удобнее. А возможность вызова из редактора означает что все эти кавычки и прочее, что обычно руками приходится писать он, тоже сам расставляет.
MVC это другой метод борьбы со сложностью SQL-строк. Интересный в первую очередь тем, что до такого вообще додумались. С одной стороны логично, а с другой всё равно смело. Не помню с какого момента (может и с самого начала) была возможность поисков и фильтров по вытащенной из базы информации. Вот они и нарастили этот метод добавив туда все мыслимые возможности и посадив надстройку прямо на таблицы базы данных. На выходе писанины, как было показано, генерируется SQL строка для выборки информации.
В 1С тоже есть неявная генерация SQL строки. Если написать:
Имя = Справочник.СправочникЧегоТо.ЧегоТо.Наименование;
… то будет сгенерирована строка типа:
SELECT @Имя = Наименование FROM СправочникЧегоТо WHERE ID= ЧегоТо
Чуть иначе это пишется, но смысл тот же. Понятно что такой запрос наименования нужен часто, значит надо как-то упростить писанину для этой операции. Кроме того, строку «Справочник.СправочникЧегоТо.ЧегоТо.Наименование» довольно просто интерпретировать и перевести в текст SQL. Интерпретаторы MVC-текстов разбирают написанные для них выражения и сами генерируют довольно сложные SQL-строки.
Немного про то, что MVC сам не умеет и почему это не страшно.
Я уже писала, что такие списки :
… удобны но плохи тем, что это нагрузка на технику при том, что они нужные не всегда а скорее даже редко. И уж совсем сомнительно это выглядит в HTML-страницах, которые будут запрашивать эти списки при каждом нажатии кнопок.
Потому придумано компромиссное решение:
Коды надо вводить строками (а не выбирать из списка). Но список легко добыть по кнопке справа.
Вот он:
Тут все так… не слегка страшненько, но цифры уже читаемые. Читаемо это в числе прочего разбивка на тысячи и миллионы. Без этого очень неудобно, т.е надо иметь возможность делать это как-то быстро и просто. А ещё, раз уже у меня все равно это выбирается на отдельную страницу, естественно видеть процент от сумм.
Вот весь текст, который мне требуется для выборки информации:
Красным отмечено то, что мне пришлось написать два раза. Это не типично и только потому что в этом запросе есть группировка (GroupBy). Если бы ей не было, можно было бы написать короче и добыть сумму по выбираемому набору одной строкой Sub(a=>a.SUMM). Расчёт процента (малиновое) тоже вставляется легко и просто. В других местах другими средствами это обычно сложнее делается. Совсем сам это делает только Access-овский отчёт.
Обращаю внимание на то что сама сумма засовывается на страницу через переменную ViewBag.TotalSum. Нет, насколько понимаю стандартных средств форматирования суммы. Посчитать её сам HTML-лист может, а информации для форматирования нет. Нет и не надо. Переменную на страницу засунуть тоже очень просто:
Выше то, что он сам посчитал, а ниже вывод той же информации из перемененной. Видимо они не придумали как логично и корректно засунуть информацию о форматировании такой суммы. Для отдельных строк его можно задать:
… а что, пририсованное тут, должно быть форматом суммы по набору строк непонятно. То, что этого нет похоже на кнопку, запрятанную в третьем подменю. Можно долго дискутировать о том, что нужно настолько часто чтобы он было под рукой и сразу. Решили что добавление такого формата с помощью каких-то заклинаний сделает текст менее читаемым и он потеряет логическую связанность.
А это описание таблицы DOC-список документов:
Повторюсь, что чтобы генерировать SQL-строки должны быть описания всех таблиц базы данных. В данном случае сверху есть строка [Table("DOC")], т.е явное задание имени таблицы (которое потребовалось только для этой таблицы). Почему-то без этого он пытался искать в базе таблицу с именем «DOCs». То, что для решения проблемы сверху надо написать такое заклинание, не догадается никто и никогда (так же как и почему он решил дополнить имя этой таблицы; это пример того как машина не поняла, чего от неё хотят, домыслила и не угадала). Решение только в Интернете можно найти после долгого поиска. Поэтому такие не интуитивные вещи стараются не делать. Особенно когда получить нужный результат другим способом очень просто.
p/s
Как драматично (с):
http://www.c-cpp.ru/content/malloc
Функция malloc() возвращает адрес на первый байт области памяти размером size байт, которая была выделена из кучи. Если памяти недостаточно, чтобы удовлетворить запрос, функция malloc() возвращает нулевой указатель. Очень важно всегда проверять возвращаемое значение на его равенство NULL, прежде чем пытаться использовать этот указатель. Попытка использования нулевого указателя обычно влечет крах системы.
… Явно машинный перевод. «Куча» это явно «dump», который никто не переводил. А вот что там было вместо «краха системы» не помню.
|
