Awesome project (again)

Mar 2, 2012 at 7:25 PM

Another awesome project (with Irony), thank you for the sharing

Every page of the tutorial is marked "Warning - this tutorial is for the upcoming version of the framework - not uploaded yet."

Any timeframe?

Coordinator
Mar 2, 2012 at 7:27 PM

 one week.

Mar 2, 2012 at 7:50 PM
Edited Mar 2, 2012 at 7:50 PM

thank you... looking forward to it.

I have written a couple of these my self, and I know the pain that it is, I found the idea to represent the record in an interface instead of a class brilliant.

There is only one tweak that I don't see in your planning.

When updating or deleting a record, for some entities, I want to keep a copy of the original record. The first time I used a status column, which with the appropiate index it was a fast solution, but it made the select queries harder. Now I create a sql that moves the record to a history table before apllying the change.

Would you add something like that? Or a way to tweak the sql generated? OR I can cooperate and work on the functionality too?

Coordinator
Mar 2, 2012 at 8:11 PM

yeah, this is known as record versioning - in some cases you not only need to keep the old version, just for archiving, but you need to actively use a certain version from the past. Like in billing for some service - the numbers in Fee definition can change, but when you present the "historical" view of charges (or recompute the charge to fix some mistake) you have to use the version of the Fee from a certain moment in the past, not the "current' value. This is a common pattern, and certainly record versioning will be coming. This kind of "custom entity module", in addition to having some extra tables in database and regular stuff like any other module, would need some "backdoor" API into VITA, to intercept and save the old version somewhere on update, or to present the "version as of date" in selects. 

I pretty much nailed down the public API for regular entity operations - that's what I describe in tutorial. But "backdoor" APIs are things to be defined as we go and as we develop these extras that require them. I would welcome any participation in the future - let's wait till I publish this version, and then we'll plan the future. I'm a bit constrained by my current employer's needs - these come first, but generic features development like record versioning would go on anyway. 

Don't worry, I have experience with real world apps (unlike some folks in Redmond), so I keep in mind all those scenarios. 

thank you

Roman

Mar 2, 2012 at 8:22 PM

great, we are in the same page, and same usage scenario.

I was looking into how clojure implement immutable structures without fully duplicating them, and the pattern is very similar, but Rickey is using a 5 bit bitmap hash to know what version of the graph node to use. Very similar with records.

On usage scenarios, once I had this request (for legal purposes) from my boss: User xyz used the system 3 months ago, can we see what he saw then?. This was a heavely used call tracking system implemented using Microsoft CRM... The answer ofcourse was no. And I hated to have to say no because the database vendor did not implemented with records what CVS has been doing with text files for decades. I added the functionality to the ERP system that I was creating for them, and it was used in several occasions.

Thank you for the time to read my rant

Jorge

Mar 3, 2012 at 9:26 AM
jorgeleo wrote:

I found the idea to represent the record in an interface instead of a class brilliant.

Yes, I like this approach too! I've had some experience with the project where entity classes were defined as abstract classes (real entity classes were generated at runtime, like Vita does). I found this approach very convenient: the developer defines entity classes with minimal efforts. Entities are kept thin and readable.

But there is one drawback, however: what if we need to extend entity classes in some way? Say, implement INotifyPropertyChanging interface (in addition to INotifyPropertyChanged implementation provided by the framework out-of-the box)? I think, the developer will need (sooner or later) some extension point to be able to plug in some custom code to the entity generation.

rivantsov wrote:

 one week.

Can't wait to check it out!

Regards, yallie

Coordinator
Mar 3, 2012 at 5:19 PM

About NotifyPropertyChanged and similar things. The difference in VITA is that both interface and generated class are not real data containers (unlike I guess the case you mention with abstract base classes). In VITA the real container is EntityRecord, an untyped name/values dictionary like DataRow in ADO.NET. All calls from typed entities to EntityRecord go through just 2 methods of EntityRecord - GetValue and SetValue. This chanelling into just 2 methods makes it really simple to intercept and fire any event you like on Get/Set/Change actions. The application would get to the record behind using utility method EntityRecord.GetRecord(entity) - already there, and then hook into it (not implemented yet). Or it would hook at session level, or at meta-data level (for all objects in all sessions). I really had this interception scenarios in mind when I designed VITA. 

thanks

Roman

Mar 4, 2012 at 7:31 PM
rivantsov wrote:

(unlike I guess the case you mention with abstract base classes).

Yes, these abstract classes are the real data containers.

rivantsov wrote:

All calls from typed entities to EntityRecord go through just 2 methods of EntityRecord - GetValue and SetValue. This chanelling into just 2 methods makes it really simple to intercept and fire any event you like on Get/Set/Change actions. The application would get to the record behind using utility method EntityRecord.GetRecord(entity)

That's absolutely great! I like this approach very much.

If EntityRecord could be replaced with a custom implementation, then it would allow almost any kind customization. In my own code I can always use EntityRecord.GetRecord(entity) to access the real data container, if entity interface is not enough.

But how should I enable, say, WinForms data binding? Should I bind controls to my entity interfaces: bookBindingSource.DataSource = typeof(IBook)? If so, then real data objects behind them should support at least INotifyPropertyChanged. What if some third-party UI framework will need some more? For example, IRevertibleChangeTracking implementation to enable "undo" feature? Is this scenario supported?

To enable this, I would auto-implement all interfaces found in a custom EntityRecord class (all calls are simply passed to the underlying EntityRecord instance).

Coordinator
Mar 5, 2012 at 7:25 PM

Honestly, not a big fan of WinForms binding, the way it is implemented. Remember when they came up with this "advanced" implementation around 2005, I was quite excited, even bought a book "Windows Forms Binding" - huge volume, and the size tells it all. I stopped browsing thru around the middle of the book. Bizillion of interfaces, for all possible "edit-view" tricks - the trouble with this is that your objects become really bloated if you wanted them to be "editable". Again, the same anti-pattern I discuss in "About biz logic" article (see on Documentation page). The problem is that even with all these fancy stuff it does not work for most real-life scenarios - tried it. 

My plan in VITA is to keep entities dumb and non-involved in "activities" logic, including winForms binding/editing. On the other hand, binding is a good concept. Where to put stuff then? not in controls of course - they are "given" and immutable. I think the solution should be a "binding controller" component that you drop on the form and which does all stuff. It hooks to control events and holds references to entities, and links both. One nice facility in WinForms in extension properties (property defined by a component "appears" in property grids of other components) - this way we can make this binding look and feel like native.

There are some advanced scenarios we can handle then. For example, string properties of entities have Size attribute (max length); the binding controller would be able to push it into the edit control; validation, errors, etc. And in the future, I plan to expose some meta-data API that will bring even more, like labels, help text/tips, default values etc. 

The point is - it all should be handled by a "side" component which knows about VITA entities; the "binding" code should not be forced into controls code or entities themselves. 

Mar 5, 2012 at 7:37 PM
rivantsov wrote:

I think the solution should be a "binding controller" component that you drop on the form and which does all stuff. It hooks to control events and holds references to entities, and links both. One nice facility in WinForms in extension properties (property defined by a component "appears" in property grids of other components) - this way we can make this binding look and feel like native.

Hilarious...

I am about a couple of weeks from releasing such component. It was born out of the frustratoin on how winforms works and how easy is to bind in wpf and silverlight. It is an extender control that adds a binder property to the controls in the form. This property is type of string, and it supports a very simple DSL to specify the bindings. some examples of bindings:

Text <= Username;
Caption <- UsernameCaption;
Password <=> PasswordProperty;
TextChanged <- ICommandProperty;

When I release it there will be mroe documentation.

Once I release the first version I can extended to support VITA.

Coordinator
Mar 5, 2012 at 7:44 PM

Great! we're already on the right track then!

Mar 6, 2012 at 8:44 AM

Hi guys, and sorry for this offtopic.

I'm not quite sure what you're talking about. WinForms data binding may be slow, cumbersome and quirky, but it works quite satisfactory. It surely can be used in a real-world apps.

@rivantsov:

>the trouble with this is that your objects become really bloated if you wanted them to be "editable".

This is true. But with VITA approach all this bloat is hidden. The developer only sees entity interfaces. Concerning performance, in most cases this bloat doesn't add much overhead.

>Again, the same anti-pattern I discuss in "About biz logic" article (see on Documentation page).

Yes, I read this article, and I fully agree that business logic should be separated from entity classes. But I don't think that the same applies to the interfaces from System.ComponentModel such as INotifyPropertyChanged, IEditableObject, IRevertibleChangeTracking, etc. After all, it's not only data binding that can make use of them — these interfaces are pretty common.

@jorgeleo:

>This property is type of string, and it supports a very simple DSL to specify the bindings.

That's interesting... Is it better than the standard DataBinding editor which allows to select properties from a drop-down list? What features does it provide that DataBinding doesn't have?

Mar 6, 2012 at 11:45 AM

"is it better"

I don't know if it is better or worse, it depends on what patterns are you using in your app. It is much better if you are trying to do MVVM, otherwise is bloat and it is worse.

"than the standard DataBinding editor"

Yes for data binding properties the standard editor is very limited. It is nice to select from a drop down, it makes programmers life easier... but I can garantee you that how easy is to program has 0 value for the users of the software. I didn't learned how limited it is untill I moved to XAML; WinForms cannot be as rich as XAML, but it is much more mature, and there is a lot that can be done to bring MVMM to Winforms that the standard editor does not provide.

"What features does it provide that DataBinding doesn't have?"

The DSL allows for multiple functionality that the standard data editor does not have. Event binding is one for example, type of binding (once, once way, two way); or what you bind like properties, or maybe a formula, or not the property value but a value in an attribute of the property.

I hope this helps.

Mar 6, 2012 at 1:25 PM

Jorgeleo, thanks for the explanation!

>It is nice to select from a drop down, it makes programmers life easier...

Well, not really. It simply prevents typos in property names.

>a value in an attribute of the property.

This mode is supported, other things like binding mode, formulas, events — certainly not.
Please make an announcement once your project is available, would really like to try it out!

Mar 6, 2012 at 10:55 PM

Ffirst alpha publish:

http://winformsmvvm.codeplex.com/

 

Attribute binding has the form of:

ViewModelProperty@AttributeClass.AttributeProperty

Coordinator
Mar 7, 2012 at 4:53 PM

thanks! will look at it as soon as I'm done with publishing the new version

Mar 8, 2012 at 9:34 AM

Jorgeleo, thanks for sharing!

Let's continue MVVM-related discussion on your project page.

Coordinator
Mar 10, 2012 at 5:42 AM

Sorry folks, promised to publish around today (a week after last Friday), but need a few more days. stuff keeps popping up. But it's almost ready, just a few ugly pieces need to be finally fixed.

Have a nice weekend

Roman