1. From legacy desktop application to Single Page Application By Jens Munk Freelance consultant

2. The application – a little bit of history Old application ~20 years Originally developed in PowerBuilder Automatically converted to c# ”Made to run” in India ”Made usable” in Denmark Several generations of technology Windows forms, WPF, embedded Razor/MVC, IBatis, ADO, OleDb, Entity Framework, WCF service layer – and lots of other technologies.

3. The application – business point of view Basically a workflow engine/state machine Excel like input – formula, calculation engine etc. And 3. party integrations to e.g. ERP systems A thick windows client Only for the administrating party of the workflow/state machine Several customers With lots of installations The application is stabile bugs are reported – but most of them can be considered as change requests An application that fits the current business needs

4. The application – technical point of view No consistent architecture exists A service layer exists … but not a service architecture The desktop application also access the database through stored procedures and DAL The database used to be an Oracle database but has been migrated to MS-SQL but without changing the naming conversions, still missing foreign keys, inconsistent data types (e.g. decimal/int/bigint) …a lightweight conversion Heavy usage of anti-pattern magic strings and numbers Nice mix of Danish and English Lots of business logic in the GUI layer Unit test coverage is less than 10% The rest is handled by manual tests I big pile of… challenges.

5. Motivation for changes Make a consistent architectural foundation Upgrade to new technology Better recruitment foundation Cheaper to implement new features Fix data consistency challanges Rapid installation Add application workflow party support Could be SaaS application

6. How to proceed? Total rewrite? No release for the next couple of years … and a shaky version The “Vista way” Bottom up conversion? Update data types and add foreign keys Add O/RM (using EF or NHibernate) Build service layer … Shaky version due to limited unit test coverage – or a huge load on test team Either way… Not an option

7. Selected approach Encapsulation pattern Side by side implementation Consistent EF model on existing database + repository pattern Only used by new code Old code is treated as black box New features developed in new technology Changes requires re-written in new architecture (and technology) Old desktop application Database EF model Repository Service layerSecurity Embedded IE SPA

8. Single-page application – in a single slide Page is loaded once (hence single page) HTML is modified based on user input and service layer response From Wikipedia: A single-page application (SPA), also known as single-page interface (SPI), is a web application or web site that fits on a single web page with the goal of providing a more fluid user experience akin to a desktop application. HTML + JavaScript + AJAX Browser Service layer Data layer …

9. Issues related to SPA Service layer security You should not be allowed to access the services if you are not authorized Entity security Data needs to be filtered on a per user/role basis E.g. getPossibleActivities(caseId) Access denied/error on unaccessible cases Different lists will be returned to case admin and to case applier Kind of row level security pattern – but in using existing security model Service layer Data layer … Authentication Authorization

10. How about in real life? Sounds easy? How about new features that use some existing business logic? That is implemented in the GUI layer? With side effects? Case by case …But in general Create appropriate test cases for the selected area (automation preferred) – for both new and old architecture Implement service in new architecture Replace old code with new service Keep side effects in old code

11. Our SPA technology choices Bootstrap JQuery ServiceStack (HTML) Template based No HTML in JavaScripts Demo/slides

12. Partial view– static part Id’er when redering is dynamic

13. Dynamic rendered HTML

14. HTML template Table row template Button template Pagination templates

15. Applied templates

16. Form validation The form is validated server side by ServiceStack. Some errors are directly related to a single field And some are global

17. Form validation Create a form with a given id Names needs to match names in request object otherwise the serializeObject() cannot be used In the save function use the formid as a parameter for clearErrors() and applyErrors()

18. Form validation Template for displaying error messages is located in the container file.

19. The anchor object Anchor object The uri must never be accessed directly always through the available methods Additional properties will probably be added

20. Current status We are not there yet … But we are well on our way And expect to have first SPA with encapsulation pattern ready Q1 2015