Obiwan Jacobi - All Comments

re: Why do we not design a class like this?

Marc Jacobi — Wed, 06 Aug 2008 14:27:47 GMT

The nested classes or structs are versioned whenever the main class is versioned. I dont see why they should be versioned independently. I would expect that because they are nested, they version with the root class that contains them...

Unless you have a property group (struct) that is reused over different (root) classes, but then its just like any other class depenedency.

I would not expect to see interfaces for each property group. These groups are merely for organizing a large number of individual properties.

re: Why do we not design a class like this?

orcmid — Tue, 05 Aug 2008 16:45:39 GMT

I think there is more to it than that. If you consider versioning of classes over time, there are some issues that come up when we use nested objects (including structures) as independently-versionable entities.

This could be handled by using versioned interfaces to carry the particular contract in an explicit way. That doesn't, of course, deal with the accomodation of WinForms and XAML.

Redoing your nested example using interfaces and their implementations is challenging. But I think the extra indirection is the key, just the same.

[My RSS feed just coughed-up these older posts of yours, so I am a late-comer to this discussion.]

re: [WPF] Data Model - View Model - View

Martijn van Asseldonk — Thu, 10 Jul 2008 08:06:18 GMT

Thanks for clearing this up and confirming my presumptions.

re: [WPF] Data Model - View Model - View

Marc Jacobi — Tue, 08 Jul 2008 12:34:32 GMT

In fact, I see that CAL also suggest the pattern.

msdn.microsoft.com/.../cc707885.aspx

Only they call it Presentation Model.

Whatever...

re: [WPF] Data Model - View Model - View

Marc Jacobi — Tue, 08 Jul 2008 11:16:04 GMT

I was not aware of CAL when I wrote this. CAL (WPF) is more a next version of CAB (WinForms). A lot of concepts seem to re-appear in CAL that were in CAB. Also CAL uses a Document-Presenter-View pattern (in the docs). I have no idea if that can be changed because I have no hands-on experience with CAL yet. It all depends on what the CAL framework assumes of a module. If its only a view (a quick look at the architecture overview seems to suggest that) than you can use DM-VM-V with CAL.

The Data Model - View Model - View pattern is way lighter than CAL. Its just a (very short ;-) description of how you could structure your code to make use of the powerful databinding features of WPF.

CAL is a framework, a library. It contains IoC/DI containers and event aggregators and the lot. All services you'll need when you want to build composite applications. The DM-VM-V pattern says nothing about composition of modules into an application.

CAB, Acropolis, CAL.... whats next!? ;-)

Composite Application Guidance for WPF

Martijn van Asseldonk — Tue, 08 Jul 2008 08:13:11 GMT

Hi Marc,

Can you tell me how this relates or differs from the patterns used in the just released Composite Application Guidance for WPF? Are the two mutually exclusive or is DataModel/View/ViewModel a (good) option to use in an app using CAL? I noticed CAL also uses the Command pattern to handle interface actions.

Could it be your described pattern is lighter and easier to use than CAL? CAL contains a lot of functionality and might be overkill for smaller apps.

Like to hear your thoughts...

re: Trace Context Aspects with PostSharp

Marc Jacobi — Sun, 20 Apr 2008 19:18:15 GMT

Yes, in a sense that I would advice them to the project team that is working for that customer ;-)

I mean, I would not burdon the customer with these details unless they are very technical and can understand what the hell I'm talking about.

re: Trace Context Aspects with PostSharp

Remco — Thu, 17 Apr 2008 11:05:12 GMT

Then, would you advise using them to a customer?

re: Trace Context Aspects with PostSharp

Marc Jacobi — Thu, 17 Apr 2008 09:46:50 GMT

Remco,

First of all my *experience* is very limited because I just started using static aspects.

But I think it is safe to say that static aspects are no less-robust or stable than ordanary custom code. This means it is up to the aspect writer to make it stable and robust. If you now use, say, a static helper class to do your tracing, that would be no different. That static helper class would need to be just as stable and robust as the aspect should be.

The nice thing about static aspects is that you can debug them just as you would 'normal' code. Also, static aspects will not change once compiled into your code (as is possible with dynamic aspect weavers). That means you can make unit-test to verify the aspect's behavior, although in some cases -depending on the aspect behavior- this could be a little difficult.

In my opinion static aspects are the most relyable and predictable type of aspects to use and they are completly transparent to the calling code.

re: Trace Context Aspects with PostSharp

Remco — Wed, 16 Apr 2008 16:10:33 GMT

Marc,

What is your experience in regards to stabillity and robustness of this solution? what happens when an aspect is buggy? this is critical behavior, when you sprinkle all these aspects accross your classes ...

A Method Context Information Gathering Framework

Obiwan Jacobi — Tue, 15 Apr 2008 14:13:55 GMT

Do you also have that feeling when you type in your tracing code that it is too cumbersome and too much

re: Why I think Merging Source Code sucks

Nathan Pledger — Thu, 20 Mar 2008 21:39:38 GMT

I've never had the luxury of using Team Foundation Server, but I can appreciate your frustration with source control. We use SVN having "upgraded" from CVS, and the whole concept is brilliant but intrisically flawed. I end up creating milestone backups of repositories "Just in case", because I couldn't trust it at all.

I'm glad I'm not on my own, as it feels at the moment!

re: Singleton Generics [updated]

mezhaka — Tue, 04 Dec 2007 10:25:52 GMT

the parameter type of the generic needs public default constructor, so the type you're using as a parameter is not singleton object itself. don't you think there maybe problems, when some other member of your team will use this parameter type instead of the using it singletoned with this generic?

re: Ploggle Desktop Application

Dennis van der Stelt — Fri, 30 Nov 2007 10:52:45 GMT

Leuk, dat Ploggle : http://manuel.ploggle.com/

re: Why do we not design a class like this?

Marc Jacobi — Thu, 30 Aug 2007 07:47:37 GMT

Taking thing to the extreme is never a good thing (unless its money? ;-).

I would think that you would only need one level in most cases (as my example). Multiple levels of property containers reeks of bad design and might justify actual classes instead of just property structs.