We Keep Coding

Is is a good practice to store propery names in a public constant string?

In order to protect ourself from failure because of any renaming of properties (Let's say you regenerate your poco classes because you have changed some column names in the relevant Db table) is it a good practice to decalre constant strings that keep the property names inside?
public const string StudentCountPropertyName = "StudentCount";
public int StudentCount {get;set;}
For example: Think about a DataBinding; where you type the property name in the DataFieldName attribute explicitly.
Or this is not a good idea and there is a better and still safer way?

It is always a good idea IMHO to move any 'magic strings' to constants.
You could consider using lambda expressions to 'pick' your properties, for example:
GetDataFieldName(studentCollection => studentCollection.Count)
You will have to implement GetDataFieldName yourself, using a bit of reflection. You can look at HtmlHelperExtensions from MVC to see how it can be done. This will be the most safe approach, which gives you compile-time errors when something goes wrong and allows easy property renaming using existing refactoring tools.

From one point of view: if you using this property name multiple times it is good practice. It will help for sure with the refactoring and when you for example change property name you see that you need change this const also.
From another point of view i guess it will be ugly when my class with 10 properties will have 10 additional consts. Another solution if you want avoid consts or explicit name typing can be getting property names through the reflection.
Use such approach or not you should decide yourself.

I think it's a common practice to put this "magical string" or "magical numbers" in some kind of strong typed store.
Something you can consider is to code it in a Aspect Orientied Way.
For example the calls to notifypropertychagned can be realized with an attribute implemented with an aop framework, like PostSharp .
[NotifyChange]
public int Value {get;private set}
This tools also have some downsides but i think there are scenarios where they can save you a lot of work

I do not know if I fully understand your question, but if I understand it right I would have used an attribute for that, an example could be the use of ColumnAttribute in Linq which you use to map a property to a specific column in a database (http://msdn.microsoft.com/en-us/library/system.data.linq.mapping.columnattribute.dbtype.aspx), like in this example:
[Column(Storage="ProductID", DbType="VarChar(150)", CanBeNull=False)]
public string Id { get; set; }
And I would never use DataFieldName, I would DataBind to the strongly typed objects (and of course also make an interface to the class that uses the property above so I easily can change the implementation in the future ;))

I suppose if the names are used in many places then it would be easier just to change them in this one place and use the constant as described in your comment.
However, a change to a database column name and object property name implies a change to your conceptual data model. How often do you think this is going to happen? In the early stages of a project, whilst conceptual modelling and implementation are paralellised across a dev team, this may be quite fluid, but once the initial conceptual modelling is done (whether this in a formalised conscious manner or just organically), it's usually quite unlikely that fundamental things like these are going to change. For this reason I think it's relatively unusual to have do this and the technique will only be productive in edge cases.

Absolutely. It's a good idea.
By the way, I would argue that these kind of things could be better stored in application settings, because you can define such things in an application configuration file later by overriding these settings.
Doing that this way you'll avoid re-compiling if some database, POCO or whatever changes, and as in newer Visual Studio versions like 2010, you can tell it to generate settings with "public" accessibility, you can share strongly-typed settings with any assembly that reference the one containing them.
At the end of the day, I'd change your code with DataBindingSettings.StudentCountPropertyName instead of a constant.
Easy to manage, more re-usable, and readable, as "you configure a data-binding with its settings".
Check this MSDN article to learn more about application settings:
http://msdn.microsoft.com/en-us/library/a65txexh(v=VS.100).aspx

Is this way of using Dictionary<enum,object> correct in this Production Planning example?

Consider a production planning application with many products. Each product has a list of InventoryControl objects keyed on InventoryControlType. Depending on the algorithm we run for production planning, we need to access to different types of InventoryControl objects for a given product. This works OK. However, today I needed to introduce a field in InventoryControl that holds the InventoryControlType since deep in our algorithms we needed to know the InventoryControlType.
However, I felt felt like I was doing something wrong since it looks like I am repeating data.
Does this design look OK to you? Any ideas for improvement?
class Product{
Dictionary<InventoryControlType, InventoryControl> InventoryControls;
GetInventoryControl(InventoryControlType type){
return InventoryControls[type];
}
}
class InventoryControl{
InventoryControlType controlType;
float limit;
float cost;
...
CalculateCost(){...}
GetConstraint(){...}
}

I think you're fine. It's perfectly normal (at least in my experience) to use a unique property of an object as a key--be it in a Dictionary, a DataTable, or what have you.
For example in my own work our major project features a class called Product with a property called Symbol, and the application maintains a Dictionary called Products with each Product object's Symbol property serving as its key.
Think of it this way: if you have a database with two tables, and one table references rows in the other by key, it may feel like you are "duplicating" data in the sense that you have the same number (the key) in two places. But that is not duplication; it's a reference. The same applies in your scenario.

I don't see anything inherently wrong with it. It is duplicating a piece of information, but the situation does call for it. You could use a normal collection instead of a Dictionary--but because your main goal is to find a piece of information based on its InventoryControlType, Dictionary, with this implementation, seems most correct.

I think it's absolutely fine for a Dictionary<TKey, TValue> use case.
Many times Dictionary objects will always have some sort of redundant information from the value object, the most common of which will be an ID, e.g. Dictionary<int, SomeObject> where int will be a value taken from SomeObject.Id -- it makes sense in that respect, and it's perfectly identical to your use case.

It really depends on how big the dictionary is supposed to get, because for very large amounts of data, I think the lookup on the dictionary using the key would probably be faster. But if you don't have very large amounts of data, you could use Linq and a Generic List. For example:
class Product{
List<InventoryControl> InventoryControls;
GetInventoryControl(InventoryControlType type){
return InventoryControls.First(x => x.ControlType == type);
}
I would recommend running some unit test benchmarks to see whether the Dictionary is required.

C# read-only calculated properties, should they be methods?

I have several entities that have calculated fields on them such as TotalCost. Right now I have them all as properties but I'm wondering if they should actually be methods. Is there a C# standard for this?
public class WorkOrder
{
public int LaborHours { get; set; }
public decimal LaborRate { get; set; }
// Should this be LaborCost()?
public decimal LaborCost
{
get
{
return LaborHours * LaborRate;
}
}
}

It's OK to use calculated properties rather than methods, as long as the calculation doesn't take a noticeable time
See Property usage guidelines

I think methods should perform actions on the object, typically change the state of the object. Properties should reflect the current state of the object even if the property is calculated. So you should keep your properties IMO.

I think they should all be properties. As long as it doesn't change the state of the object, I'm cool with it as a property.
Additionally, if I'm using your class for data binding (WPF, etc.), then I can bind directly to your property without having to modify/extend the class.

If they are a) lightweight and b) have no side effects, I would make them Properties.
Lightweight is a bit fuzzy of course, but the rule of thumb is: If I ever have to worry calling a Property (be it in a loop or anywhere else), it should possibly be a method.

I would leave them as properties. But there's not "standard" reason to do things one way or another. If you're by yourself, do whatever you like best. If you're on a team, then follow conventions the rest of your team are following.

If a property is particularly expensive to calculate, I might change it to a GetWhatever() method. This serves as a hint to whoever uses my class that this value requires some significant work to arrive at, and the caller should cache the value rather than calling the method multiple times.
Trivial calculations are perfectly appropriate inside of properties.

In my opinion, it's a preference; it's what you want to do. I do propreties in most cases, unless there is logic involved. Additionally, if you need to pass in parameters to change the functionality then obviously a method would apply...

Depends, if your "properties" become mammoths and require a whole slew of business logic they shouldn't be properties, there should be a method.
The example you posted looks ok to be a property. No standard way of doing it, go with your gut instinct; if it looks like it needs to do a lot you probably need a method.

It's largely just syntactic sugar anyway, so do want you is convention in your team, or what you prefer, as long as it is just returning information about the object and not changing it or interacting with other objects.

MSDN gives information about this here
Class library designers often must
decide between implementing a class
member as a property or a method. In
general, methods represent actions and
properties represent data.
Which one do you think it is? An action calculate/getLaborCost or data?
WorkOrder workOrder = new WorkOrder();
workOrder.LaborHours = 8;
workOrder.LaborRate = 20;
decimal cost = workOrder.LaborCost; // This is OK here
but if you are going to do this for the same object also:
worOrder.LaborHours = 18;
decimal newCost = workOrder.LaborCost
Now this cannot be a property. It would be a lot better to be a method.

Sometimes, you have to consider also what you're modeling... On some domains, the calculated values are often or expected to be an attribute of the model -- a Property. If this were the case, then write it as a Property even though the calculation is not at all trivial or a little bit expensive to compute. Just document it on your API or implement some caching mechanism to minimize recomputation for this property.

Pattern for Plugins - IoC/DI or not?

Just a very general question, that not only applies to this example.
Let's say you have an Online Shop and you want to implement Vouchers/Gift Certificates, but with Constraints. Let's say you have a voucher for 20% off, but that applies only to products added within the last 3 weeks, but not to ones in a special promotion.
I see two ways to solve it: The first way is to code your shop to "natively" support all crazy types of vouchers. This seems to be the classic way, but it means a lot of work beforehand and very little flexibility (After all, you can't know beforehand what you need, and maybe Sales may come up with some really great new promotion which requires new vouchers - by next Monday).
The second way is a Plug-In way: Vouchers are like Plugins and each Voucher has it's own Code. You pass in the Shopping Basket into the Voucher and then the Voucher itself checks each item if it applies, makes the neccessary changes and returns the changed shopping cart.
I just wonder, what is the Design Pattern for Case 2? It looks a bit like IoC/DI, but then again not really because Vouchers are not replacing any existing functionality. It's more like a set of Object with a Special Interface (i.e. IVoucher), and then a Queue of IVoucher Object that gets iterated over. Is there a standard pattern (and best practice) for these types of "Manipulators"?
Edit: Thanks for the Answers. To clarify that just a bit, the Vouchers (or Manipulators - as said, this is not only a question about online shops but about a similar situations) are "heavy" objects, that is they have Business Logic in them. So I can say that a Voucher only applies if the Customer signed up before January 1 2008, only if the customer ordered at least 100$ in the past 6 months, only applies to articles in the Category X, "stacks" with other Vouchers except for Items marked as Reduced etc. etc. etc. So my concern was more about how to keep a clean structure to make sure the Vouchers get all that they need to check whether they apply and to be able to manipulate the Cart, so I wondered about what the standard for such situations are, which is exactly what the Visitor Pattern seems to do.

It's a case where you could use the strategy pattern along with the vistor pattern to calculate the value of the basket.
A vistor could visit each item in the basket utilising different strategies (in this case discount vouchers) and using those to calculate the full cost of the basket.
The vouchers used could be retrieved from a database in some way and injected into the visitor quite easily.
The voucher strategy could look something like this:
public interface IVoucher
{
decimal CostOf(CartItem cartItem);
}
The default would be something like this:
public class FullPriceVoucher : IVoucher
{
public decimal CostOf(CartItem cartItem)
{
return cartItem.Cost;
}
}
A 10% discount would be something like:
public class TenPercentOffVoucher : IVoucher
{
public decimal CostOf(CartItem cartItem)
{
return cartItem.Cost * 0.9m;
}
}
Then you could have a visitor for calculating cart value like this:
public class CartValueVisitor
{
private IVoucher voucher;
public CartValueVisitor(IVoucher voucher)
{
this.voucher = voucher;
}
public decimal CostOf(Cart cart)
{
return cart.Items.Sum(item => voucher.CostOf(item));
}
}
Which you would use like:
var cart = GetACart();
var fullPriceCartValueVisitor =
new CartValueVisitor(new FullPriceVoucher());
var tenPercentOffCartValueVisitor =
new CartValueVisitor(new TenPercentOffVoucher());
var fullPrice = fullPriceCartValueVisitor.CostOf(cart);
var tenPercentOffPrice = tenPercentOffCartValueVisitor.CostOf(cart);
This obviously only works with a single voucher at a time but should give you an idea of the general structure.

The previous answers suggesting Visitor and Strategy patterns sound fine to me, although Visitor is overkill in the typical case where each purchase item is an object of the same concrete class. The purpose of Visitor is to allow dynamic dispatch on two (or more) object types -- the visited objects are part of one hierarchy, and the visitors are part of another. But if only one object type (the concrete type of the class implementing IVoucher) varies, then regular old single-type virtual dispatch is all you need.
In fact I personally wouldn't bother with any "pattern" at all -- your own description is exactly what's needed: create an interface, IVoucher, and a bunch of classes that implement that interface. You'll also need a factory method that takes a voucher code and returns an IVoucher object having the appropriate concrete type.
Beware Non-Commutative Vouchers!
The fact that you mention a queue of IVoucher-implementing objects will be run against the purchase items implies that more than one voucher may be used. In this case you need to be careful -- does applying voucher A, then voucher B always have the same effect as applying B then A? Unfortunately many typical "special offers" would seem not to have this property (e.g. if voucher A gives you $10 off and voucher B gives you 5% off, the order definitely matters).
A quick and dirty way out of this is to assign each voucher a distinct numeric "priority" value, and always apply vouchers in priority value order. To reduce the probability of "weird" combinations of vouchers driving you bankrupt, it's probably also a good idea to limit voucher combinations to some set of allowed combinations specified in your code somewhere. (This could be as simple as a list of lists of voucher codes.)

Maybe the Visitor pattern? The different types of vouchers are the visitors, which visit the shopping basket and manipulate it.
I don't think IOC is the solution here.

Best way to get a list of differences between 2 of the same objects

I would like to generate a list of differences between 2 instances of the the same object. Object in question:
public class Step
{
[DataMember]
public StepInstanceInfo InstanceInfo { get; set; }
[DataMember]
public Collection<string> AdHocRules { get; set; }
[DataMember]
public Collection<StepDoc> StepDocs
{...}
[DataMember]
public Collection<StepUsers> StepUsers
{...}
}
What I would like to do is find an intelligent way to return an object that lists the differences between the two instances (for example, let me know that 2 specific StepDocs were added, 1 specific StepUser was removed, and one rule was changed from "Go" to "Stop"). I have been looking into using a MD5 hash, but I can't find any good examples of traversing an object like this and returning a manifest of the specific differences (not just indicating that they are different).
Additional Background: the reason that I need to do this is the API that I am supporting allows clients to SaveStep(Step step)...this works great for persisting the Step object to the db using entities and repositories. I need to raise specific events (like this user was added, etc) from this SaveStep method, though, in order to alert another system (workflow engine) that a specific element in the step has changed.
Thank you.

You'll need a separate object, like StepDiff with collections for removed and added items. The easiest way to do something like this is to copy the collections from each of the old and new objects, so that StepDiff has collectionOldStepDocs and collectionNewStepDocs.
Grab the shorter collection and iterate through it and see if each StepDoc exists in the other collection. If so, delete the StepDoc reference from both collections. Then when you're finished iterating, collectionOldStepDocs contains stepDocs that were deleted and collectionNewStepDocs contains the stepDocs that were added.
From there you should be able to build your manifest in whatever way necessary.

Implementing the IComparable interface in your object may provide you with the functionality you need. This will provide you a custom way to determine differences between objects without resorting to checksums which really won't help you track what the differences are in usable terms. Otherwise, there's no way to determine equality between two user objects in .NET that I know of. There are some decent examples of the usage of this interface in the help file for Visual Studio, or here. You might be able to glean some directives from the examples on clean ways to compare the properties and store the values in some usable manner for tracking purposes (perhaps a collection, or dictionary object?).
Hope this helps,
Greg