Transcript From legacy desktop application to Single Page Application

From legacy desktop application
to Single Page Application
By Jens Munk
Freelance consultant
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.
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
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.
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
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
Selected approach
• Encapsulation pattern
• Side by side implementation
• Consistent EF model on existing
database + repository pattern
Old desktop
application
SPA
Embedded IE
• Old code is treated as black box
Repository
• New features developed in new
technology
EF model
• Changes requires re-written in new
architecture (and technology)
Database
Security
Service layer
• Only used by new code
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.
Browser
HTML + JavaScript + AJAX
Service layer
…
Data layer
Issues related to SPA
• Service layer security
• You should not be allowed to access the
services if you are not authorized
Authentication
• Data needs to be filtered on a per
user/role basis
Service layer
• 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
Data layer
Authorization
• Entity security
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
Our SPA technology choices
• Bootstrap
• JQuery
• ServiceStack
• (HTML) Template based
• No HTML in JavaScripts
• Demo/slides
Partial view– static part
Id’er when redering is
dynamic
Dynamic rendered HTML
HTML template
Table row
template
Button
template
Pagination
templates
Applied templates
Form validation
• The form is validated server side by ServiceStack.
• Some errors are directly related to a single field
• And some are global
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()
Form validation
• Template for displaying error messages is located in the container file.
The anchor object
• Anchor object
• The uri must never be accessed directly always through the available methods
• Additional properties will probably be added
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