Честно говоря, я думаю, что вы просите о том, чего на самом деле невозможно сделать.
Я уверен, что есть технологии, которые могут облегчить динамически привязанную модель данных, которая вам нужна (я видел нечто подобное, написанное в Visual Basic 6.0, но это решение вызывало проблемы с производительностью при доступе к данным, когда их набор данных начинал увеличить масштаб). Разница между LightSwitch и VB 6.0 заключается в том, что VB 6.0 позволял вам динамически создавать экраны и изменять привязку данных во время выполнения - и этому способствовал тот факт, что приложения VB6.0 связываются поздно - у них есть наследие до .net VB работает как интерпретатор времени выполнения. Вывод LightSwitch компилируется .Net MSIL - особенно на стороне сервера. Несмотря на то, что этот код компилируется только до MSIL, а не до языка ассемблера или машинного кода, он строго типизирован и имеет раннюю привязку.
LightSwitch выполняет привязку данных во время компиляции к уровню сервиса, генерируя код на основе шаблонов T4, которые работают с данными и моделями экрана в соответствующих файлах .LSML, и расширяя базовые классы с помощью дополнительного кода программной части / добавленного JavaScript по мере необходимости. Если вы не создаете сервисы на лету, я не понимаю, как LightSwitch может связывать экраны (простой момент в этом сценарии) с сервисами, которые не существуют, когда вы запускаете свое приложение.
Следует также отметить, что LightSwitch обычно ожидает, что сущности в модели данных будут строго типизированными. Даже если бы вы смогли создать службу, которая переводила сущность пары ключ-значение (то есть объект словаря) во что-то, что выглядело бы как строго типизированный набор табличных данных, доступный для операций CRUD, производительность при доступе к данным была бы совершенно ужасной, и без базы данных, оптимизированной для арбитража внешних ключей, уникальных ограничений, объединений таблиц и т. д. тьфу Я не вижу, чтобы она когда-либо была настолько производительной, как реляционная база данных. Некоторая база данных NoSQL может улучшить производительность, но тогда вам понадобится служба, которая переводит запросы LightSwitch LINQ to Entities в операции сокращения карты, специфичные для платформы.
Я не говорю, что то, о чем вы просите, не может быть выполнено каким-либо абсолютным образом. Если бы вы составили данные экрана в виде XML-документов, которые можно было бы записать в столбец с типом XML в таблице SQL Server, это могло бы быть осуществимо. Чтобы это сработало, вам, вероятно, потребуется включить какой-то ссылочный документ схемы XML (или внешний ключ для таблицы, содержащей такие ссылочные XSD в типе XML), чтобы иметь возможность развернуть документы экрана по мере необходимости.
Однако я не думаю, что Silverlight будет лучшей технологией для создания экранов на основе этих XSD или привязки данных уровня хранения данных к службе, которая предоставляет такую модель данных, ориентированную на XML. Возможно, вы даже сможете запечатать этот процесс в шаблоне экрана, но в конечном итоге Silverlight слишком строго типизирован и оптимизирован для раннего связывания. HTML-клиент будет иметь гораздо больше смысла, поскольку вы можете перехватить событие create () при отправке HTML для экрана и событие экрана before_ApplyChanges () для сериализации данных экрана в XML для передачи по сети. Однако то, что вы делаете, будет эффективно заменять практически все, что излучает LightSwitch, кроме CSS.
На мой взгляд, вам было бы лучше сделать это с чем-то вроде приложения ASP.NET MVC, поскольку вы могли бы построить модель вокруг схемы KVP, построить шаблоны представления, которые эффективно применяют перевод XSLT к вашей схеме / данным XML для выполнения тяжелых подъем, который вам нужен, и у вас не будет дополнительных слоев кода (например, канализации LightSwitch) между вашими сгенерированными экранами и динамической моделью данных. Динамический (экран) в динамический (данные) намного проще и будет более эффективным, чем решение, которое больше похоже на динамическое (экран) на строго типизированное (подключение экрана Silverlight) к еще более строго типизированному (модель службы сущностей) на динамически типизированное ( XML-хранилище).
Помните, что существует причина, по которой существует строгая типизация. Работает хорошо. Это приносит результаты. Если у вас есть четкий набор бизнес-требований, которые могут быть выполнены только с помощью динамических форм и данных, обратите внимание на использование архитектуры решения, оптимизированной для этого шаблона. IMO, LightSwitch (помните - ранняя привязка с использованием сгенерированного кода) - это не та архитектура, которую вы ищете. машет руками, контролирует разум джедаев :)
person
Ozziemedes
schedule
21.10.2014
