Friday, February 5, 2021

My road to a useable MVVM Pattern implementation for Delphi!

If you read my blog regularly, the MVVM topic will be nothing new to you.

But please take your time and fill out my new survey, thanks for that, of course, even if you visit my blog for the first time. I would love it if you can also be part of this survey. 

If you are a first-time-reader... Welcome to my blog. Please read the other posts about my #D.MVVM implementation. As you can see, this subject is not new to me and my knowledge has, of course, improved over the years. (I hope, I'm right with this statement)



Here are the links to my other MVVM-related blog-posts in reverse order:

There was a blogpost from Oct. 2019 with the question: How long does it take to develop a "complete MVVM framework for Delphi. (Link above) the answer is: Not long if you take shortcuts or too long if you are a single developer with no help. But I won't cry, because my goal was not to do it the easy way.

If you do not make it down to the end:
Here is the link to my new survey!
But perhaps you want to know why I've created a new one? ;-) 


Let's collect - one more time - my goals:

  1. The framework must be as fast as possible. (My goal is - it is supposed to be the fastest MVVM framework available for Delphi.)
  2. The development time should not be significantly longer than using the RAD-Approach. At best, the development time should be shorter, comparing to a non MVVM, but not "everything in the Form unit" - development.
  3. Everything that could be done in a background thread should be done in a background thread.
  4. Support for FMX and VCL. Including the "special needs" for the FMX UI.
  5. It must definitely run on ALL platforms.
  6. 100% Unit-Test-able of your Application. (Switch for disabling the background thread to do a better Unit-Testing).
  7. Mockup's for View-Components to test the Binding of your App.
  8. A nice Wizard should be installed into the IDE to create a new VCL or FMX-MVVM Application. This Wizard should be changeable over an Ini-File to make a User-Configuration without recompiling the Wizard-DLL.
  9. One central binding point (Composition.Root) 
  10. If you are an FDK-User (My Firemonkey-Development-Kit) the framework should work streamless as a plugin, with all the benefits of my ORM-Lite, threading, or Client-Server units.
  11. No need for special components. (Components must work without an extension)
  12. Open to User-Implementation for non-standard components.
  13. The View (Form) should not have a single line of code. Or should not need any code-behind...
  14. Visual Livebindings must not be used.
  15. A developer who has NEVER dealt with MVVM has to get along with my framework IMMEDIATELY.
  16. A good developer who has already used MVVM should find his way around immediately. (Except for some things that I have implemented differently than MS).
  17. We are Delphi-Developer - If we are doing MVVM differently than our C# friends - that's fine!
  18. Views must be able to be composed of any number of sub-Views (frames) without writing a single line of code for them. (Sub-Views must be interchangeable for special requirements)
  19. It must also be possible for a sub-View to be a ViewPort3D (FMX-Only). Full support of 3D objects from the ViewModel will be another thing for further investigation. This could be very interesting for Game-Development, but that is completely another topic.
  20. User-Level and flagged Menu-System with auto Action-Binding.
  21. Multiple View for a ViewModel, also with sub-View/ViewModel Binding.
  22. Conventions over definitions.
    1. This is especially true for automatic binding by naming convention. Example: Name: TEdit should auto bind to the fName: TProperty<String> or to a normal property Name: String. The Binding is connected to the Text-Property of the TEdit Component and the OnChange and OnChangeTracking (FMX Only) event should update the ViewModel.
    2. User-defined naming convention... Bind Name:TEdit to fEdNameField : TProperty<String>
    3. Global naming rules and also naming rules by TypeInfo.
    4. Overwrite any predefined rule with an attribute.
  23. Multi-Binding to different properties.
    1. Example: Save: TButton.OnClick -> Procedure DoSave
    2. Save :TButton.Enabled -> fCanSave : TProperty<boolean> or Property CanSave : boolean
    3. Fone : TCombobox.Items -> fFoneItems : TListProperty<String>.
    4. Also user-defined naming: "Can"+Save;"Do"+Save could be changed to: e.G.: -> "CheckFor"+Save;"Execute"+Save.
  24. Optimal performance on ".Strings";".Items";".Lines" - never ever send the complete list on a single change. A virtual created adapter must take care of the updates. (e.G. for a single changed line in a Memo of 10.000 lines it is a nogo to update the Text-Property of the Memo.)
  25. Data-Verification on Property-Level to check the fields inside the ViewModel.
  26. Listview and Listbox special treatment for FMX.
  27. A data model for VCL Grids - The FMX Grid already has a data model.
  28. A not so easy implementation of an MVVM-Treeview. (Perhaps not in the Beta)
  29. Complete logging of all internal functions should be possible. (Only for the Plugin Version)
  30. Error messages that are normally written in English must be able to be translated by an external language file.

The MVVM-Pattern has the Model included in the Pattern-Naming, but actually, the Model is not really a part of the Pattern. But in my case:

  1. Only if the Framework supports the transfer of all the collected data from the ViewModel to the Model, my goal of: "As fast as RAD Development" is possible. 
  2. The Framework must have a Datacontext that can make the transfer from the ViewModel to the Model, and back.
  3. The Datacontext should be able to convert, combine and separate fields as they are transferred back and forth.
  4. The Model should directly work as an ORM or REST-full Web interface. 
  5. As an FDK-Plugin it should also work with my Client-Server-REST-Units.

So far so good...

There is light at the end of the development tunnel! I'm really happy with the actual implementation. I think I have done all the necessary improvements for the first version. and - as always - I would have programmed the framework even if I wasn't planning to offer it commercially. Of course, programming is a bit different when the source code is handed over to other developers. Certainly, I could have made a lot of things more static or simpler.

And now?

There will be a Beta-Version and an Early-Bird-Order! But maybe this time I should do an Alpha -Version too - if I can find developers interested in helping me finish the release version.

But how and why?

After years of development - only in my spare time, of course - perhaps I've done something wrong, perhaps I should rename a method or change params of a function. Whatever... I don't want to make breaking changes from Beta to Release.

I know - some of you - are waiting for the release of my Framework, but besides the old survey, I don't know how many Developers would still like to be part of the Alpha or Beta-Team. (or even would like to buy my #D.MVVM-Framework). (Old survey filled by 177 Users).
I've talked to some of these developers and they can't wait to get started with my framework. (I'm super happy to hear that, of course).

A comment in advance from René Höger:
"Is a lot of information! Those who have dealt with this, I think will be hot on it! I don't know what your feedback is so far, but I think this could be a milestone. When I think of all my old applications! But maybe I am biased because I have already received an introduction into your framework!" 

💖 Thanx René!

Perhaps I need to write some kind of NDA contract (never done before). One thing I want to avoid, after all these hours, is to find my Source-Code as a zip on a hacker site.

Before I could start the Alpha-Phase, I have to:
  1. Open up a ticket system or some kind of bulletin board?
  2. Perhaps a discord server?
  3. Perhaps a slack group?
  4. Think about how to collect User-contributions...
  5. Think about contribution benefits?
  6. Late or discount payment for Alpha & Beta users? 
How do I distinguish between a developer who "just" wants to see cool source code and a developer who wants to actively contribute to the framework? Maybe I should just assume the best and trust that Delphi developers are all super nice people who are interested in using this technology. I think I'll stick with that idea or a very little "fee" just to check if the developer really wants it? Perhaps some kind of reward system?

If you've made it down here - Thanx for reading and please be so kind and fill out my survey!


Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)