Re: Rick's comment: >>It's funny how the so many hard things are super easy in .Net, but how the easy things are super hard. One look at the FUBAR'ed databinding in .Net will give you a good idea <s>... <<

Absolutely true. I've spent a lot of my off-time the last week writing my first .NET WinForms test app between VFP projects, and the data binding code is god-awful, complex, finicky and improperly documented. I just wanted to write a data entry form base class. Ha! Little did I know...

Don Meuse
Spectrum Software
Miami, FL




>Chris,
>
>I think it will take time to get this all. I for myself have been holding back because I think I need to understand how .Net works a lot better before I can start building an architecture even for my own applications.
>
>The way data works in .Net is very different from how it works in other environments and to the designer this is somewhat problematic. Furthermore because .Net is strongly typed it's difficult to do certain things that were trivial in VFP like creating data member objects on the fly and bind to them.
>
>In .Net the inability to quickly EVAL() and even worse to use anything dynamic returned it is a big hinderance to building a flexible framwork quickly, IMHO. I would like nothing better than to have a wwBusiness type framwork in place - and I do, but it's not nearly as flexible or easy to use as in VFP.
>
>The dilemma for me at least is how to deal with the data representation. If you decide you go with ADO.NET all the way, you're pinning yourself to that architecture by using ADO.Net components in the front end layer (accessing fields, or DataSets). If you don't want to do manual databinding etc. this is almost a must. But if you do go that route you lose out on potential other easier ways to handle data like Serialization which let you take entire object graphs and persist them easily to disk. FOr example, I have a Web Monitoring app that has about 100 sites attached and I simply have a master object that contains an array of site objects as well as a configuration object - that object simply saves and that becomes the database. Trying to use something like this in the same environment is not easy when you force the framework to use ADO.Net. Even if you use an XML datasource for ADO.Net things get tricky.
>
>A framework needs to be easy, flexible, yet powerful without taking up to much overhead. At this point I have not found a good balance to address even half of these points with .Net <g>...
>
>As to Distributed capability I think that it will be hard for anything that uses any kind of object abstraction to *not* be able to function in a distributed manner. Web Services certainly are the easiest route in .Net as all the infrastructure is handled both for persistance of objects and data (datasets are just objects that know how to persist inline of object graphs for example), but even if you do things manually it's very, very easy.
>
>I've been able to do all of these things for years with wwXML in VFP too, but a lot of pain went into making that work with VFP <g>. Not the VFP part really but interpreting the standards and keeping up with it. Having this as part of the dev environment reduces overhead and relieves some of the burden to keep up OS tools.
>
>It's funny how the so many hard things are super easy in .Net, but how the easy things are super hard. One look at the FUBAR'ed databinding in .Net will give you a good idea <s>... but the good news is that if we don't like it we can build our own controls.
>
>I think it'll all take time to gel, Chris. Kevin's been doing a lot of work with this and from what I've seen he's really got something good going there, although the framework is fairly complex...