Typecasting interfaces to keep code loosely coupled and LiveBinsings

[Carlos Tré 9]

Dear fellow programmers,

 

I'm trying to stick to Nick Hodges advice and keep the code loosely coupled, separating business from presentation, and observing oop principles. In order to accomplish this I:

1) code against interfaces;

2) adopted a sort of MVVM design pattern. Sort of because i don't really understand the difference among MVVM, MVC, MVP, etc. I thought that if I have business logic, view logic and persistence logic in separated units, apart from the views, and fully testable, I'd would be Ok to go;

3) I use Spring4D all around because in the future I want to take advantage of it's dependency injection capabilities.

 

When it came to implement LiveBindings I stumbled into a problem: in order to create the adapters I need the actual classes, and to make the class implementation details visible in the module I call ViewModel would defeat all the isolation I accomplished so far. The solution I came up with is to keep interfaces in one module, implement them with abstract classes in another codeless module, and inherit from them and writing all the code in a third unit. I could keep the interface and it's abstract implementation in the same unit, both have no code, or separated and add another level of organization.

 

That said, I kindly ask for your input on the solution I came up with. My goal is to keep Nick happy with interfaces, keep Delphi happy with classes, and myself happy with Spring4D. Is this the way to go or is there a better solution?

 

Thank you so very much in advance .

 

Best regards,

Carlos Tré

 

[Stefan Glienke 2002]

I think in the DI book there is a chapter about injectables and creatables. Stuff that you bind to UI are usually creatables thus objects and should not have a problem.

Binding interfaces is almost if not entirely impossible in a clean way because they simply don't have property RTTI.

[Carlos Tré 9]

1 hour ago, Stefan Glienke said:

I think in the DI book there is a chapter about injectables and creatables. Stuff that you bind to UI are usually creatables thus objects and should not have a problem.

Binding interfaces is almost if not entirely impossible in a clean way because they simply don't have property RTTI.

Hello Stefan.

 

Yes, there is. And I remember you've told so some time ago, when I was toying with REST DataSnap and run into a similar situation. What bothers me is that if I need to create objects for every UI class a great deal of decoupling will be gone. In your opinion, the use of an intermediate abstract class is too much of a kludge or a time bomb just waiting for the worst possible moment to explode in face?

 

On the other hand, thinking while typing this reply, if I skip the interface declaration for UI objects, and stick to abstract classes to hide the implementation details, I'll be as good as, right? 

 

Well, they joy of old dogs insisting in learning new tricks, senile moments get in the way mora and more. 🙂

 

Thank you so much for your time.

[Stefan Glienke 2002]

I was not talking about making classes for UI controls but exposing your dataobjects in a way that you can bind them in some way to the UI.

Personally I don't like LiveBindings that much - and I gave up on some MVVM-ish approach for Delphi.

 

What works kinda well is going the DB aware approach with datasets (can use things like the TObjectDataSet from Spring4D or other similar ones - DevArt for example has also one) that just are adapters to non dataset/database data such as lists of objects.

 

There are other approaches such as my TTreeViewPresenter that connects an IObjectList from Spring4D to a TVirtualStringTree to display and even edit data.

[Carlos Tré 9]

I've failed to mention it is for a FMX application, so dataware is not possible. 

 

Once again, than you very much for your input, I'll try not to overdo things which, unfortunately, I only notice way down the road.

 

[David Champion 48]

@Carlos

this link may be of some use, a MVVM library which targets both FMX and VCL.

No interface binding was available at the time of the blog.

https://blog.grijjy.com/2018/01/22/mvvm-starter-kit-part-1-of-3/

Edited January 19, 2020 by David Champion

[Carlos Tré 9]

@David Champion

 

Thank you very much, I'll look into it right away.

 

-- Carlos

[pcplayer99 11]

Hi,

 

I do not know MVVM, MVC etc.

 

My experience is you should using interface in your code. And you should not using implement them with abstract classes.

 

Abstract classes is not for interface. If you have another reason to using abstract classes you just use it but not for interface.

 

For example, the framework of Delphi WebService is based on interface, and Delphi DataSnap framework is based on class. I like WebService framework but DataSnap framework.

[Carlos Tré 9]

On 1/29/2020 at 2:02 PM, pcplayer99 said:

Abstract classes is not for interface. If you have another reason to using abstract classes you just use it but not for interface.

For example, the framework of Delphi WebService is based on interface, and Delphi DataSnap framework is based on class. I like WebService framework but DataSnap framework.

Hi @pcplayer99

 

Thank you very much for your input. I went on with it just for the sake of my overdoing things impetus, and it worked all right. But, in the end, I think it's just not worth it, a lot of extra coding to get a hell of a kludge. On the bright side I now have a better understanding of the border separating "creatables" and "injectables".

 

-- Carlos

[Javier Tarí 23]

On 1/15/2020 at 11:12 PM, Stefan Glienke said:

I gave up on some MVVM-ish approach for Delphi.

I'm quite convinced to go the MVVM way, but your affirmation stopped me dead. Could you please tell why, so I can also abandon all hope? 

[Stefan Glienke 2002]

14 hours ago, Javier Tarí said:

I'm quite convinced to go the MVVM way, but your affirmation stopped me dead. Could you please tell why, so I can also abandon all hope? 

I am not stopping anyone from exploring that area and I would be happy if someone comes up with a solution.

However the way that Delphi, the IDE and the common UI frameworks work imo stands in the way of something that I would consider a good solution.

 

Imho two key parts of MVVM are the painless bindings and the declarative approach to specify the wiring.

In WPF most of the wiring goes into the xaml and much of that can be validated and does not rely on magic strings as it does with current solutions in Delphi.

MVVM frameworks/libraries in JS can go further and elegantly be integrated into the html code (such as Knockout.js or Aurelia).

 

Then if that is not enough reactive programming pushes such approaches even further as you can see with ReactiveUI and others.

While we have event handlers in Delphi the implementation of them is typically done very differently from that reactive does (treating events as a kind of stream of events where you can apply all kinds of operators and behavior)

[Carlos Tré 9]

18 hours ago, Javier Tarí said:

I'm quite convinced to go the MVVM way, but your affirmation stopped me dead. Could you please tell why, so I can also abandon all hope? 

It was past time I'd come back and share my conclusion.

 

I'm not well versed in OOP, I'm just an old dog — *very* old, btw  — and lack the mind sharpness I used to have back in the day. The best I could come up with in order to make the implementation independent was to drop the interface approach completely and go the abstract class way. That better implementation tool or technology waiting around the corner will pose no problem. Also, they tend to be simple classes since they model data entry controls, so they don't require exhaustive testing.

 

Thank you all for the input provided.

 

Best,

Carlols

Edited February 17, 2020 by Carlos Tré
typo

[Andrea Raimondi 13]

On 1/15/2020 at 11:12 PM, Stefan Glienke said:

Personally I don't like LiveBindings that much - and I gave up on some MVVM-ish approach for Delphi.

LiveBinding looks very cool at the beginning... until you try something more meaningful 😄

I mean, Maurizio Del Magno's IORM solution seems to provide a neat MVVM implementation, but I am also in the camp "I don't really like the MVVM approach" as it's usually defined (i.e. chock full of RTTI etc.).

I'd rather the compiler enforce things than having exceptions at runtime.

 

But MVVM per se isn't a bad idea: you can do it pretty much the same way ASP.NET core does which isn't bad at all.

The basic idea is this:

Say that you have a TUser class with all of its properties (Name, UserStatus, etc.): this is your model.

Then you have a TLoggedUser class with only the relevant information for the logged user (i.e. a Token, the UserStatus, etc.) and this is one of your ViewModels. You can have as many ViewModels as you need based on one single model. 

What happens then is that you only deal with ViewModels everywhere else than where you need to deal with the model (which is usually not user-facing). 

That approach I like and I think is sensible. TMS Aurelius allows you to do something like this by using a MultiModel setup.