Articles D.MVVM - At what point is a framework actually ready for publication? by Frank Lauter

[emailx45]

D.MVVM - At what point is a framework actually ready for publication?
Frank Lauter - 28/8/2020

Спойлер: Content

[SHOWTOGROUPS=4,20,22]
German version: Для просмотра ссылки Войди или Зарегистрируйся

Besides a few bug fixes and the typical everyday things, my focus is still on my Delphi MVVM framework.

# D.MVVVM
Why, because I want to port all of my old applications to it and I have made up my mind not to start a new project until the framework is ready, so I don't get the idea of either using an older version of it or not using MVVM at all.

I also have the "dream" that I will be able to port our 35 year old main VCL application from D2007 directly to 10.x - # D.MVVM -, preferably directly to the FMX.
So I have to make sure that I can label the framework as finished, which means that I also have to set the required functions to the status "finished".

Of course, as we all know: a project like this, like any other application, never has the status "finished". So how do I find out if I'm just improving? OK. First of all, I need a feature list. I really would like to have a unit test for every feature. Second, I need adequate documentation. (Oh man, that's a critical point. I don't have any documentation at all - until now).

But what about "clean" source - or at least cleaning up the code (a bit)? Yes, it is definitely necessary.

How do you find out if an entry in the feature list is a really necessary feature and not some nice functionality that I just want to add? I really enjoy reading your comments on this. What are the core functions that you think must be included in version 1.0, my framework?

Before we try to collect some functions, we should define some rules.

When we implement an application with the MVVM pattern we want to:

1. No or almost no code in the view! Except for UI stuff!
2. If you compare a RAD app with an MVVM app, an MVVM app should be just as easy to create.
3. The bindings are the biggest problem, they need to be as easy to set up as possible.
4. No use of anti-patterns. (Some people already call a ViewFactory an anti-pattern)
5. Ideally, you can simply create both types of "forms" and compile with the same code base for VCL or FMX.
6. Every part of our application should be unit-testable, i.e. no dependencies between the modules.
7. The shift concept must be retained.
8. The framework should work without the need for the FDK. (I had to duplicate some things)
9. D.MVVM is integrated into the FDK as a plug-in in order to benefit from all advanced functions.
10. The visual live bindings should not be used.
11. Everything should work without clicking non-visual components or special components on a form.
12. Naming conventions are preferred over configurations.
13. We don't care if a C # developer thinks we're doing everything wrong!

Anything else?
Those who know me know that I don't like to click things "together". I prefer to do everything in the code - except the form of course - so that every change shows up in the source code repository. Maybe I'll end up creating some components to suit the needs of RAD development, but that's not decided yet.

While I am making a feature list, I can also create some tickets to follow the development process.

My D.MVVM framework should contain:

1. A wizard to create a new D.MVVM application.
2. A wizard to create a new view (form or frame).
3. A wizard for creating a new ViewModel.
4. A wizard for creating a new model.
5. A framework (VCL & FMX) independent derivation of the TForm implementation to give every form a basic functionality. (finished)
6. A central point for all joins or viewchains. (finished)
7. All included VCL and FMX components should be bindable.
8. Third-party components should fit easily into the binding scheme.
9. Bindings from the View to the ViewModel should be possible without writing a line of code. (finished)
10. Connections from the ViewModel to the model should also be possible without any code. A value converter should be able to be integrated into the data transfer. (finished)
11. A data context should hold the data in memory for display. (completed but not fully tested)
12. Some basic services should be included. (Action service, navigation service, menu service, dialogue service, time service) 90% done.
13. A list adapter for handling large amounts of data for grids, list boxes and memos. (completed)
14. Public unit test with 100% code coverage. (Some are done but I didn't measure the coverage)
15. VCL and FMX demo applications. (some are done)
16. Documentation.

I believe this isn't the final version 1.0 list yet, but almost.

Again, after Для просмотра ссылки Войди или Зарегистрируйся - I need to do some heavy refactoring ...

If you have any suggestions for me, I would appreciate your comments on this topic!

Not yet dealt with the topic of MVVM? Then please check out my Для просмотра ссылки Войди или Зарегистрируйся for my already published Для просмотра ссылки Войди или Зарегистрируйся .

Please also Для просмотра ссылки Войди или Зарегистрируйся my channel and click on the "Like" button, this will help build my Для просмотра ссылки Войди или Зарегистрируйся .


[/SHOWTOGROUPS]