Nuget Cleanup

[MovGP0]

Cleanup of NuGet Templates and Code Snippets.

• fixed whitespaces
• removed unneccesarily namespaces
• made fields readonly and sealed classes
• added a main view in the nuget package, so that developers can start more easily

[michaellperry]

There should really be a separate view for each target platform. This XAML would only work in WPF, not Store, Phone, or Silverlight.

If you do create views for each platform, please be sure that the files are put in the proper content folders. Where it is now, the file wouldn't be added to the NuGet package.

Beyond that, this PR is mostly opinions. I happen to agree with the readonly opinion, but I disagree with the sealed opinion. We can have a separate discussion about those.

[MovGP0]

Am 20.11.2014 05:07 schrieb "Michael L Perry" notifications@github.com:

There should really be a separate view for each target platform. This XAML would only work in WPF, not Store, Phone, or Silverlight.

I totally agree with you. Unfortunately, I am not familiar with Store, Phone, and Silverlight development :-(

Maybe you can help me to provide good examples?

If you do create views for each platform, please be sure that the files are put in the proper content folders. Where it is now, the file wouldn't be added to the NuGet package.

I see. Hopefully I can find some time on the weekend to figure it out where the folder belongs to and fix the issue. Should not take too much time.

Beyond that, this PR is mostly opinions. I happen to agree with the readonly opinion, but I disagree with the sealed opinion. We can have a separate discussion about those.

The sealed keyword is indeed very opinionated.

I personally see it as something like the private keyword in C++ and the readonly keyword. You may not need it and it does (almost) nothing for performance. But it's a good habbit forcing developers to think and refactor before they use a property/field/method/class/etc. it in a way that was not originally intended.

Another advantage is, that the compiler can potentially do certain performance optimizations with typecasting. However, to my knowledge, such techniques are planned but not yet implemented in the current C# compiler generation. So I guess this is more about personal preferences for now.

Btw: speaking of performance: There should be implementations of IEquatable on the entity/model classes to reduce typecasting.

It is also a good habbit to use ReferenceEqual(that, null) and ReferenceEquals(that, this) instead of the 'that == null' and 'that == this', so that the == operator can be overloaded without the need to change the Equals() methods.

Specially because the overloading of the == operator, so that it tests for value equality instead of reference equality, is expected for immutable objects.

[MovGP0]

almost forgot:

Avoid object.Equals(this, that), since it leads to a boxing of the two objects and relies on reflection to compare the objects. For short, it hurts performance.

Implement IEquatable and call Equals(that) instead. Am 20.11.2014 06:08 schrieb "Johann Dirry" movgp0@gmail.com:

Am 20.11.2014 05:07 schrieb "Michael L Perry" notifications@github.com:

There should really be a separate view for each target platform. This XAML would only work in WPF, not Store, Phone, or Silverlight.

I totally agree with you. Unfortunately, I am not familiar with Store, Phone, and Silverlight development :-(

Maybe you can help me to provide good examples?

If you do create views for each platform, please be sure that the files are put in the proper content folders. Where it is now, the file wouldn't be added to the NuGet package.

I see. Hopefully I can find some time on the weekend to figure it out where the folder belongs to and fix the issue. Should not take too much time.

Beyond that, this PR is mostly opinions. I happen to agree with the readonly opinion, but I disagree with the sealed opinion. We can have a separate discussion about those.

The sealed keyword is indeed very opinionated.

I personally see it as something like the private keyword in C++ and the readonly keyword. You may not need it and it does (almost) nothing for performance. But it's a good habbit forcing developers to think and refactor before they use a property/field/method/class/etc. it in a way that was not originally intended.

Another advantage is, that the compiler can potentially do certain performance optimizations with typecasting. However, to my knowledge, such techniques are planned but not yet implemented in the current C# compiler generation. So I guess this is more about personal preferences for now.

Btw: speaking of performance: There should be implementations of IEquatable on the entity/model classes to reduce typecasting.

It is also a good habbit to use ReferenceEqual(that, null) and ReferenceEquals(that, this) instead of the 'that == null' and 'that == this', so that the == operator can be overloaded without the need to change the Equals() methods.

Specially because the overloading of the == operator, so that it tests for value equality instead of reference equality, is expected for immutable objects.