This project is read-only.

Some things

Oct 26, 2010 at 9:56 PM

Dennis,

thank you very much for the nice example I learned some nice things already. I have some comments, questions and improvements. Which I will post in this discussion.

- Have you installed resharper, if so please look at those comments, especially on the unused usings. Example: About.xaml.cs has more unused usings as other code ;-)

- Replace all "" by string.Empty, this saves some work for the garbage collector

- For a reference application some additional comments by methods and properties will be usefull

- I miss the unit / integration tests

- The code behinds for some views could be deleted entirely: Like the Search.xaml.cs. Caliburn.Micro will handle this for you.

- In the SearchViewModel you have the methods: TrackRecipeChange and UntrackRecipeChanges. These methods are already available in the Screen baseclass: So you could simply replace the code by IsNotifyfying = true / false;

- On the SearchViewModel, the type of the collection of recipies is Enumerable. I read that the Caliburn.Micro collection type: BindableCollection does the marshalling to the UI thread automatically. I did't try it out

- I think having a ServiceAgent both on the client and server is confusing. In my own caliburn.micro test application I named the clientside "ServiceProxy". What if you get a lot queries / commands, would you split it up per viewmodel or ...?

Hope this helps. Looking forward to the upgraded version with NHibernate 3 beta

I think about copying this example, but implement it with Castle as IoC container, including the WCF integration facillity, so you won't need the client side proxies.

Coordinator
Oct 27, 2010 at 8:22 PM

Hey Superstom (?), thanks for taking the time to provide me with some feedback. See my response below.

Have you installed resharper, if so please look at those comments, especially on the unused usings. Example: About.xaml.cs has more unused usings as other code ;-)

Obviously I have. But I have to admit I didn't spend too much time on that, yet.

Replace all "" by string.Empty, this saves some work for the garbage collector

I don't think that will have a noticable effect. I even think the compiler will intern the "" string.

For a reference application some additional comments by methods and properties will be usefull

Agreed. I'll pay more attention to that.

The code behinds for some views could be deleted entirely: Like the Search.xaml.cs. Caliburn.Micro will handle this for you.

Agreed.

In the SearchViewModel you have the methods: TrackRecipeChange and UntrackRecipeChanges. These methods are already available in the Screen baseclass: So you could simply replace the code by IsNotifyfying = true / false;

No, it doesn't. The reason why I do that to be able to detect if a rating for an individual recipe has been changed by the user. That has nothing to do with the PropertyChangeBase Screen subclasses.

On the SearchViewModel, the type of the collection of recipies is Enumerable. I read that the Caliburn.Micro collection type: BindableCollection does the marshalling to the UI thread automatically. I did't try it out

You're correct, but in this case I don't mind the collection changes because I always assign a new collection to the property.

I think having a ServiceAgent both on the client and server is confusing. In my own caliburn.micro test application I named the clientside "ServiceProxy". What if you get a lot queries / commands, would you split it up per viewmodel or ...?

It's a matter of taste I think. From my point of few point the client and the server are depending on an external service. The ServiceAgent is in charge of dealing with that intelligently.