>>>>I am moving more and more from the idea from having the fwk doing everything developed by one vendor -
>>>>even with vfp fwks there was the need to tweak at the fwk level (but perhaps I am a compulsive tweaker...)
>>>>and with java/.net fwks spanning greater areas I see more and more benefit in the python approach to take well-defined
>>>>building blocks and glue them together. Write the necessary to glue in a different component if necessary.
>>>>
>>>I agree and to a great extent that is what this is evolving into for me. I like Devforce's extension of the EF, then there are module and region things in Prism that are very cool. MEF or Unity? Haven't decided yet on DI. MVVM has "frameworks" of its own - e.g. Cinch. Now I'm looking at Caliburn Micro and trying to evaluate if Actions rather than inheriting from iCommand is going to have implications down the line I won't like - and still have to check how well my DevExpress UI stuff is going to play with any of this.
>>
>>I go for the big architectural picture - like always communicate with just the adjacent layer (the thing MS coorected iwith MVP and MVVM compared to MVC), communicate from the outside going in (and if there is really a UC for the other direction, comment twice as much as when the pain begins), build conglomerats of objects instead of god objects and so on. Also convention before configuration is a great time saver.
>>And if I see nontrivial amounts of non-DRY code, I ditch the package without further thought if that is not changed after a mail to the fwk authors pointing out a few of those places.
>
>Have you any thoughts on some of the popular MVVM ( or MVVM friendly ) "frameworks" - ie. Caliburn.Micro, MVVM LIte, Cinch, Prism or combinations of these?
>
>Right now I"m digging through the full Prism and I understand the "overkill" argument but it also seems that once you have a basic prism app skeleton it can be Nugetted into reusabliity.

[Disclaimer: I know some of my posts/mails are msiunderstood/ because I have a tendency to assume common background as evident/given, which on realistic thought cannot be asumed]

I am not far into Dotnet application dev - I tried my hand to find out the capabilities of Ironpython and the capabilities C# gained compared to Java in the last years. I was especially impressed with C#, which is the leader of the pack in the javaesque languages of non-P-Code compiled languages [sorry for the negative definition, but this comes closest while still missing the javascript V8 engine - sigh].

I view aspect programming with a partly quesy stomach feeling. In itself the abundance of meta tags in the code is perhaps partially a try to compensate for language deficiencies. [So bad smell is coming from the language typicals, while the developer tries the best in the given surroundings to clean the air]. DI is clearly better than re-implementing interfaces, but in dynamic languages you handle all those UC's having only 1 significant method in the class and instantiating different classes according to config files by simply monkey-patching the "action" method - which OTOH is needed there, as class instantiation has a heavier cost in dynamic environments.

But another part comes from the often blindly followed "model first" or "viewmodel first". I am still in the old camp of "datamodel first" [partly because from personal UC: I seldom am called to create from scratch] and mirror many of Hank's ideas of utilizing metadata at database level. One of the UC of DI is reusing validation rules in biz layer, sometimes in the UI for single field validation in desktop apps and perhaps even at the DB level. But a large percentage of validations follows very simple patterns like "not empty", "between [range]" or relationship rules.

In my book the the parameters/properties of these validation rules have to be delegated into the DB, moved automatically into the biz/M/VM layer and read out from the UI layer if [evtl. disconnected] client-side field validation for a specific field is asked for. In such a design you can recur to a standard library or default behaviour without the need to create special DI-Behaviour, without the need to modify config / UI XML files as the query identifying the data source also "publishes" (read: grants access, not "sets in upper layer") the validation DB default parameters up to any interested level. In the case where you have a desktop app in C# and a web app with javascript controls the same automatic validation occurs (if the standard routines are equivalent) without the need to modify different UI XML files. I know that much of this could also be handled via a more OO-handling (even at CSS-level) of the XML files, where both UI recur to a configuration describing a common model including validation parameters - but at least MS programatic designers are not always that smart - and for the DB level the support is still missing.

After dissing much of the need for DI I might send you to LightCore - here I like the (untested by myself) speed claims of nearly basic Dotnet instantiation times and the support for all really needed ways to call it up. [Have not checked if there are english articles on LightCore]. Also in reading up the CastleProject I see they dismiss Fowlers description in their WindsorCastel IOC component rather forcefully...

I had encounterd caliburn micro and found the description of caliburn micro stressing convention along Ruby lines refreshing. Cinch I started to read - I like the authors style and way of thinking so far, for instance the further seperation of code behind files but I prefer running through a library vs. generating code.

Too bad we cannot discuss those things face2face and not via keyboard -
might be more on topic and more productive.

regards

thomas