Как разработать приложение типа MS CRM - PullRequest
2 голосов
/ 22 сентября 2010

Я работал с MS CRM. Там мы можем разработать наш пользовательский объект графически, а затем мы можем также создать визуальную форму для выполнения операций CRUD над этим объектом.

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

То, что я хочу знать, это то, как они достигают всего этого динамически? Если мне нужно создать CRUD на одной простой таблице, мне нужно написать хороший объем кода. Как MS достигает всего на лету? Любые указатели, любой документ будет очень полезен.

1 Ответ

0 голосов
/ 23 сентября 2010

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

Вот как я думаю, что это, вероятно, сработает / или грубо, как вы могли бы сделать это ...

Компоненты

Системе потребуется набор компонентов или подсистем; они могут быть написаны вами или существующими библиотеками (используйте существующие библиотеки, если можете):

  • CMS некоторого рода, если только вы не хотите встроить это в систему, которая у вас уже есть.
  • Компонент / элемент управления пользовательского интерфейса, который позволяет пользователям создавать свои "объекты". Чтобы это было сделано хорошо, для этого потребуется довольно продвинутый пользовательский интерфейс (SilverLight? HTML5?) - хотя я думаю, вы могли бы использовать что-то действительно простое.
  • Какой-то способ хранения пользовательских "объектов" - это в основном данные, и вы хотите сохранить их в каком-то "нейтральном" хранилище.
  • То, что делает настоящий CRUD - я думаю, что-то вроде инструмента ORM, такого как Entity Framework, Lightspeed, NHibernate. Вам также понадобится цель источника данных для самих операций CRUD.

Хитрость в пунктах 2 и 3; Здесь я бы определил набор атрибутов, которые можно использовать для определения созданных пользователем объектов. Эти атрибуты - то, что логически объединяет процесс. Поскольку атрибуты могут быть прочитаны во время выполнения:

  • Они смогут управлять пользовательским интерфейсом, который позволяет пользователям составлять свои "объекты".
  • Когда все будет готово, вы можете создать фактические классы, которые физически реализуют определенные пользователем объекты, а затем украсить эти объекты соответствующими атрибутами.
  • Каким-то образом инструмент ORM знает, как сопоставить свойства этих объектов (на основе атрибутов) с хранилищем данных, или написать DAL самостоятельно - может быть, DAL обернет ORM?

Другой подход, который я использовал, в значительной степени основан на этом, но он также использует интерфейсы, и данные хранятся в виде «блоба» XML - не конкретных дискретных метаданных.

...