When to NOT use DDS in Optimizely CMS
Simple checklist when to NOT use the dynamic data store ORM build in mapper in the CMS.
Episerver CMS 11 and Optimizely CMS 12
Optimizely DDS is a built in ORM mapper to store simple objects into the database.
When to NOT use Dynamic Data Store:
If you need any of these functionalities it is probably better to look for alternatives
- Versioning
- Sorting
- Projects
- Relations
- Wysiwyg-editor
- User Interface
- Drag n drop UI
- Localization
- Build in validation
- Publishing
- Content approval
- Eventhandling
- Good performance (over 1000 items)
Alternatives to DDS
- Implement IContent as a custom object
check this blog => https://www.epinova.se/nyheter-och-blogg/utvecklarbloggen/2014/custom-icontent-with-its-own-navigation-pane/ - Implement IContent as a block (store it in the “for this page” container, and/or in IContentArea)
- Entity Framework => https://blog.setapp.pl/migrate-entity-framework-episerver
Further reading
- https://world.optimizely.com/documentation/developer-guides/CMS/dynamic-data-store/
- https://blog.setapp.pl/custom-data-episerver-dynamic-data-store (four parts – how to store custom data in Optimizely CMS)
- https://marisks.net/2017/10/19/fixing-dds-mapping-issue/ (Fixing mapping issue with DDS)
- https://vimvq1987.com/dynamic-data-store-is-slow-but-you-can-do-better/ (Dynamic Data Store can do better when its slow)
About the author
Luc Gosso
– Independent Senior Web Developer
working with Azure and Optimizely
Twitter: @LucGosso
LinkedIn: linkedin.com/in/luc-gosso/
Github: github.com/lucgosso