Там допустимые причины состоят в том, чтобы содержать данные внутренне как XML?
Попробуйте:
With xlApp.ActiveSheet.Pictures.Insert(PicPath)
With .ShapeRange
.LockAspectRatio = msoTrue
.Width = 75
.Height = 100
End With
.Left = xlApp.ActiveSheet.Cells(i, 20).Left
.Top = xlApp.ActiveSheet.Cells(i, 20).Top
.Placement = 1
.PrintObject = True
End With
Лучше не выбирать что-либо в Excel, обычно это никогда не требуется и замедляет ваш код.
8 ответов
Любые данные, хранящиеся в памяти, должны быть в классах. Чем выше объем данных, о которых мы говорим, тем важнее это становится. Xml - это сильно раздутый формат, снижающий производительность. Xml следует использовать только для передачи данных между приложениями. ИМХО.
No, I agree. For your first example, the database should handle almost all the caching, so storing all the data in program memory is wrong. This applies whether it's stored in-memory as XML or otherwise.
For the second, you should convert the XML into a useful representation as soon as possible, probably a database, then work with it that way. Only if it's a small amount of data would it be appropriate to do all work in-memory as a XmlDocument (e.g. using XPath). String parsing should be used very sparingly.
Я тоже согласен и думаю, что здесь есть элемент невезения.
... но, хватаясь за соломинку, я видел единственное использование данных, хранящихся в виде XML, - это автоматические модульные тесты, где XML предоставляет простой способ моделирования тестовых данных. Но определенно того не стоит.
@ Мэтью Флашен очень хорошо замечает. Я хотел бы добавить, что когда вы присоединяетесь к какому-либо существующему проекту, вы, вероятно, найдете некоторые решения по дизайну и реализации, с которыми вы не согласны.
Мы все постоянно узнаем что-то новое, и все мы делаем ошибки. Хотя я согласен с тем, что это похоже на проблему типа "ага", я уверен, что другие разработчики пытались оптимизировать код с помощью концепции кеша.
Дело в том, что иногда требуется мягкий подход, чтобы убедить люди, особенно разработчики, чтобы изменить свой образ жизни. Это не проблема кодирования, а проблема людей. Вам нужно найти способ убедить этих разработчиков, что предлагаемые вами изменения не означают, что они некомпетентны.
Я предлагаю согласиться с ними в том, что кеширование может быть отличной идеей, но что вы ' Я хотел бы поработать над этим, чтобы ускорить работу функций. Создайте быструю демонстрацию того, как работает ваша (более логичная) реализация по сравнению со старым способом. Трудно спорить с резким улучшением скорости. Просто будьте осторожны с прямой атакой на способ, которым они реализованы в разговоре. Вам нужно, чтобы эти люди работали с вами.
Удачи!
I've found that I've had to do it to interact with a legacy COM object. The COM object could take either xml or a class. The interop overhead to fill each member of the class was way too large and processing xml was a much faster alternative. We could have made a c# class identical to the COM class, but it was really too difficult to do in our timeframe. So xml it was. Not that it would ever be a good design decision, but when dealing with interop for huge data structures, it was the fastest we could do.
I do have to say that we are using LinqtoXML on the C# side, so it makes it slightly easier to work with.
For high volumes of data the answer is no, there aren't good reasons to store data directly as XML strings in memory.
However, here is an interesting presentation, by Alex Brown, on how to preserve XML in memory in a more efficient way. As a 'Frozen Stream'.
There is also a video of this, and other presentations given at XML Prague 2009 here.
Грег,
в нескольких приложениях я более или менее точно следовал описанной вами схеме:
Правка: не царапайте это. Я никогда не хранил XML в виде строки (или нескольких строк). Я просто проанализировал это в DOM и работал с этим. ЭТО было полезно.
Я импортировал источники XML в DOM (Microsoft Parser) и сохранил их там для всей необходимой обработки. Я хорошо осведомлен о накладных расходах памяти, связанных с DOM, но, тем не менее, я нашел этот подход весьма полезным.
Для некоторых проверок во время обработки требуется произвольный доступ к данным. Оператор selectPath вполне подходит для этой цели.
Узлы DOM могут передаваться в приложении как аргументы. Альтернативой является написание классов, охватывающих каждый отдельный тип объекта, и их обновление по мере развития схемы XML. Это' это плохой (VB6 / VBA) подход к полиморфизму.
Применение XSLT-преобразования ко всей или части DOM несложно.
О вводе-выводе файлов также позаботится DOM (xmldoc.save .. .)
Связанный список объектов потребляет сопоставимый объем памяти и требует больше кода. Все функции поиска и ввода-вывода мне пришлось бы кодировать самостоятельно.
То, что я воспринимал как анти-шаблон, на самом деле является более старой версией приложения, в которой XML был более или менее вручную разбит на массивы структур. .
Все функции поиска и ввода-вывода мне пришлось бы кодировать самостоятельно.То, что я воспринимал как анти-шаблон, на самом деле является более старой версией приложения, в которой XML был более или менее вручную разбит на массивы структур. .
Все функции поиска и ввода-вывода мне пришлось бы кодировать самостоятельно.То, что я воспринимал как анти-шаблон, на самом деле является более старой версией приложения, в которой XML был более или менее вручную разбит на массивы структур. .
как насчет ООП и баз данных? Xml имеет его использование, но могут возникнуть проблемы (как вы видите) с его использованием для всего.
Базы данных могут допускать индексацию, транзакции и т. Д., Что ускорит ваш доступ к данным
Объекты в большинстве случаев проще для работы, они дают лучшее представление о вашем домене и т. д.
Я не против использования xml, но это похоже на шаблоны, это инструменты, которые мы должны понимать, где и когда их использовать, а не влюбляться в них их и стараемся использовать везде ...