#D.MVVM - At what point is a framework ready for release?

Besides some bug-fixes and the typical daily stuff, my focus is still on my Delphi-MVVM-Framework. 

#D.MVVM

Why, because I want to port all my old applications to this and I promised myself not to start a new project until the framework is ready so that I don't get the idea of either using an older version of it or not using MVVM at all.

There is also a dream, that I'm able to port our 35 years old main VCL - Application from D2007 direct to 10.x - #D.MVVM - at best direct to FMX.

So, I have to make sure that I can call the framework finished, which means I also have to set the needed functions to the status "finished".

Of course, we all know: With such a project, as with any other application, there is never the status "finished". So how do I find out when I'm just "tweaking" it? Ok. first of all, I need a feature list. I would really like to have a unit test for each feature. Second I need sufficient documentation. (Oh, boy this is a breaking rule. I have no documentation at all - so far).

But what's about clean code - or at least cleaning up the code (a little bit)? Yes, this is 100% necessary. 

How do you find out, if an entry in the feature list is a really necessary feature and not some nice functionality I just want to add? I really like to read your comments about this. What are the core functions, you think must be included for a 1.0 Version of my framework?

Before we try to collect some features we should define some rules.

To implement an application with the MVVM-Pattern we want:

1. No, or nearly non-code in our View! Except for UI stuff!
2. Comparing a RAD-App with an MVVM-App, MVVM-App should be as easy to create.
3. The bindings are the biggest problem, they must be as easy as possible to set up.
4. No use of Anti-Pattern. (Some people are calling a ViewFactory already an Anti-Pattern)
5. At best: Just create both kinds of  "Forms" and you could compile it to VCL or FMX with the same codebase.
6. Every part of your application should be unit-testable, so no dependencies between your modules. 
7. Don't break the layer concept.
8. The framework should work without the need of the FDK. (I had to duplicate some stuff)
9. D.MVVM integrates as a plugin to the FDK to benefit from all the higher-level functions.
10. Don't use the visual live bindings.
11. Everything should work, without clicking non-visual components or special components on a form.
12. Naming conventions over configuration.
13. Don't care if a C# developer thinks you are doing it wrong! 😄

Anything else?

If you know me, I really dislike clicking things "together". I like to do everything in code - except the form of course - so that every change is noticeable in the source-code repository. Perhaps I create some components at the end, to fit the needs of the RAD-Development, but that is not yet decided.

While creating a feature list, I can also create some tickets to keep track of 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 to create a new ViewModel.
4. A Wizard to create a new Model.
5. A Framework (VCL & FMX) independent overload of the TForm implementation to give every Form some base functionality. (done)
6. A central point to do all the joins or Viewchains. (done)
7. All included VCL and FMX components should be bindable. 
8. 3rd party components should be easy to include in the binding schema.
9. Bindings from the View to the ViewModel should be possible without writing any line of code. (done)
10. Bindings from the ViewModel to the Model should also be possible without any code. A value converter should be included in the data transfer event. (done)
11. A data context should keep the data in memory to be displayed. (done, but not fully tested)
12. Some basic services should be included. (Action-Service, Navigation-Service, Menu-Service, Dialog-Service, Time-Service) 90% done.
13. A List-Adapter for handling huge Data in Grids, Listboxes, and Memos. (done)
14. Public Unit-Test with 100% code coverage. (Some are done, but I have not measured the coverage)
15. VCL and FMX demo Apps. (some are done)
16. Documentation.

I think this is not the final version 1.0 list yet, but almost.

Again: After watching Uncle Bob's clean code lessons - I have to do some heavy refactoring...

If you have any suggestions for me, I would be very happy about your comment on this topic!

If you're reading my blog for the first time, please take a look at my Youtube Channel for my already released D.MVVM-Videos.

Please don't forget to subscribe and hit the like button to help me grow my Channel.