> {quote:title=Joanna Carter wrote:}{quote}
>
> I'm sorry but, as someone who has spent the past six years or more
> designing MVC/MVP frameworks, first in Delphi and then in C#, I would
> say that your assumptions were wrong.
Don't be sorry, it seems people on the web are labeling what they are trying to implement in Delphi as MVC/MVP even when it's not. So, I wanted to attract their attention. I do know that those patterns are not even necessarily implying the existence of a UI. But, I wanted to let people know that if they take some time to think about the BO model they can use Delphi to implement a fine solution that is flexible. In other words you can easily replace the UI or the data storage and can easily replace the con
nector(s) between the UI and BO or between the BO and data storage. Keep in mind I just started using the MVC/MVP terminology. But I think the idea is to separate the UI from the BO and use connections to link them for flexibility and varying views. I've been coding a five layer UI -> connector -> BO -> connector -> Storage approach for a while even before I heard of MVC/MVP so I'm sure my view is different from the "accepted" view of those patterns. However, the Delphi components (I've just now started i
mplementing the patterns with the standard components) are doing a pretty good job of implementing the five layers/parts for me.
> Yes, you would use forms as views but there are other types of views
> that are not forms.
Well, I don't know if I would say a form is gonna' be the view.
> The DataSource, ClientDataset approach to connecting UI elements to
> properties of objects is, at worst crude, at best difficult to achieve.
I find it quite easy to achieve and working fairly well. Keep in mind with your extensive experience you're probably a bit more strict on the definitions than I am. But, I've been swaping UIs and RDBs with ease (test apps mind you). One issue is, I've been exposing my business object methods so that they can easily be visually linked to UI elements and that presents a problem for me because I don't know if that should be it's own connector (number three) or if it should be a part of the standard connector
> Neither DatasetProvider not SQLDatatset have any place in the MVP/MVC
> patterns, they belong solely in an OPF framework.
Right, I understand storage is not fitting well in the accepted definitions. But, I see quite a few people including it in their questions of how to implement their ideas.
> Such a solution is far from optimal and is, at best, a major kludge when
> compared with the bindings that are available in .NET for Windows or
> Cocoa for OS X.
Hmm... Since I'm not a less is more because the code will run faster person. I can only say that I like how things are going so far. But, I understand your point and am not stating "this way is the right way". I'm saying hey if you are doing what I'm doing, designing your business object model then trying to make an app from it using Delphi. Take some time to investigate the current data controls and you'll see you can separate the UI, BO, and Storage but you can do it with a frame work that makes it quic
k to complete.
Thx, Joanna, I knew you would chime in.