The Myth of the External MVP Framework
Table of Contents
Introduction
If you’re working with UI components and are looking to implement a Model-View-Presenter pattern (MVP), you will find a plethora of MVP frameworks that claim to be able to work with whatever UI components you happen to be using.
The thing is, an “external” MVP framework like this only makes sense if you are working with incredibly primitive UI components.
If you are working with any modern components, such as SmartClient, Sencha, or even agGrid, MVP is already part of the framework.
When you try to bypass built-in MVP features to instead work with an external MVP model, you turn your powerful UI components into dumb renderers, throwing away the best parts of their functionality.
Specifically, if you were to remove the built-in MVP features from SmartClient, you would turn our powerful ListGrid component into a dumb HTML <table> renderer with a JavaScript array as the data model.
The ListGrid would no longer automatically know how to use a remote data service to fetch, filter, sort, page data, save edits, or validate changes.
Re-creating each of these features is going to require hooking low-level ListGrid events and APIs to call your MVP framework, and a colossal effort to recreate all the built-in functionality.
Further, even if you invested 20 man-years in this effort, you still wouldn’t match SmartClient’s superb built-in MVP functionality.
This is why we say that the “external MVP framework” is a myth.
There are only two possibilities:
- the MVP framework has value because you’re working with incredibly primitive components – which you shouldn’t be
- the MVP framework has negative value because it destroys built-in MVP functionality
In a nutshell, the value of external MVP frameworks ranges from useless to much worse than useless.
To make this clear, let’s take a look at SmartClient’s built-in MVP model. We will find that:
- it works with any conceivable source of data
- it minimizes the amount of code you have to write
- it has an ideal design for testability & isolation testing
- it’s extremely flexible, with overrides at every conceivable point in processing
The MVP Model in SmartClient
SmartClient DataSource: The Heart of the MVP Model
In SmartClient, the built-in MVP model is centered around the Model (called a “DataSource”).
The DataSource expresses the structure of an object, including its fields, field types, and validation rules.
The DataSource also offers a standard request and response protocol, which covers all the standard CRUD details, such as expressing criteria and sorting, requesting row ranges for data paging, error handling, and more.
When you give a DataSource to the main data grid component (“ListGrid”), the ListGrid immediately configures itself to view and edit records from that DataSource.
With no additional configuration, the ListGrid component offers fetching, searching, sorting, data paging, editing with validation and saving, and many other features.
UI Comprehension of DataSources
All of SmartClient’s UI components understand DataSources and how to use them.
For example, with the form component (“DynamicForm”), you can simply give it a DataSource, and it will present a complete form for editing those records.
It can save changes and display validation errors in various ways.
Similarly, when you give a DataSource to a ComboBox or other drop-down, it just works.
The same goes for trees, data cubes, menus, and all other UI components in SmartClient.
With all of these components, there is a default binding to the DataSource which will show all of the fields you define on the DataSource, but you can also do fine-grained customization of that binding.
The SmartClient architecture is designed to ensure that you never repeat the information that comes from the DataSource, even if you customize heavily.
The Pluggable DataSource
You can implement the DataSource (the model) however you like.
The UI components just see the standard DataSource API, so they don’t know whether they are talking to SQL, REST, or WSDL.
You can swap out the DataSource implementation, and no changes need to be made to the UI.
There are pre-built DataSource implementations, such as RESTDataSource, which give you a complete JSON or XML protocol for server contact.
These pre-built implementations specify exactly how things like nested criteria, multi-level sorts, or aggregations are requested over REST, and provide a standard format for how the server responds, including how errors are reported.
All you need to do is implement that REST protocol on your server, and you’re done.
SmartClient also offers various starter server implementations for Node, .NET MVC, PHP, and more, which take that REST protocol and connect it to SQL DBs.
Finally, there is a Java-based commercial server that offers very deep functionality for SQL/JPA/Hibernate, including things like built-in auditing and calculated fields.
This Java server also gives you the ability to write your own custom connectors in Java, without having to worry about the REST protocol from the browser: you just work with nice clean Java request & response objects.
Isolation Testing & Parallel Development
SmartClient also features a “client only” DataSource implementation which fully simulates a remote data service.
You just give it some sample data and you’re ready to go.
Client Only DataSources can even simulate complex operations like joins and aggregation.
Using Client Only DataSources, your client-side team can immediately start building a fully testable UI while your server-side team is building the real data services.
When the server side is complete, the server-based DataSources can be swapped in, and nothing in the UI needs to change.
You can even set up dynamic switching so that you can return to Client Only mode at any time.
This helps make it clear whether a given problem is a client-side or server-side issue.
How to Fail with an External MVP Framework
As we’ve seen, SmartClient’s built-in MVP features provide a powerful and streamlined approach to building web applications.
However, some developers may resist this approach, insisting that an external MVP framework is necessary for their needs.
To illustrate this point, let’s look at a hypothetical conversation between a developer (DEV) who wants to use an external MVP framework and an experienced SmartClient developer (ISO).
DEV: “I need a low-level API where I can intercept the ListGrid’s requests for data.”
ISO: “OK, when a ListGrid tries to request data, it sends a DSRequest to its DataSource, and then in the DataSource, you can fulfill that however you like.”
DEV: “Oh, we can’t use that.”
ISO: “…why?”
DEV: “We have our own MVP, and we’re not using DataSources.”
ISO: “Why would you use a separate MVP framework when MVP is baked directly into SmartClient?”
DEV: “I just read about this other MVP pattern, and it looked cool [usually with some odd references about “separation of concerns,” “testability,” and other things already handled exceptionally well by SmartClient].”
ISO: “OK, but you’re throwing away everything that makes SmartClient special, downgrading our powerful components to dumb renderers, and you will reinvent the wheel over and over.”
DEV: “I’m OK with all that. So where is the low-level API where I can intercept the ListGrid’s requests for data?”
ISO: “That’s DSRequest. It encapsulates everything the grid needs to send to a data service, and then the DSResponse encapsulates the response.”
DEV: “Can’t use that because we are not using DataSources. What’s another low-level API?”
ISO: “…why would we have more than one API with exactly the same purpose? The DSRequest is exactly what you’re looking for -“
DEV: “Man, your framework sucks. I’m going to go read the source code and hack some undocumented internals.”
“DEV” always fails, in the same way, every time: he sits down to write 1000s of lines of unnecessary code. After months of effort, he is still nowhere near replicating the functionality we show in simple examples with 10 lines of code.
Don’t be DEV.
Summing up
Built-in MVP features are essential because they provide a consistent, easy-to-understand model for working with UI components.
The MVP model in SmartClient is based on the DataSource, which is at the heart of the SmartClient architecture.
They help ensure that components work together seamlessly, without the need for additional code or third-party frameworks.
By using built-in MVP features, you can streamline your development process, improve your application’s performance, and avoid “square peg/round hole” problems altogether.
The myth of external MVP framework is just that – a myth.
When working with UI components, it’s essential to use built-in MVP features, which provide a consistent and effective model for working with these sophisticated components.
By using the built-in features, you can streamline your development process and avoid unnecessary problems, ultimately delivering a better application to your users.
