Programmatically, you have bigger object to pass around when you need to edit parts of the object (such as category name based on category id).
Logically, you have single blob of properties instead of domain objects that accurately model your app workspace.
This particular situation also shows some design problems (but it may be a requirement so take this considering your own domain):
- you should not have category and subcategory as separate objects (assuming parent - child relationship implicated by subcategory catid property) - they are both categories of various "levels" in a tree
- item could also have multiple categories so you could have List<category> categories; instead of single category (again, depending on the requirements)
- in the item, single category id would take care of sub and main category due to parent-child relationship
Instead (I would) create category like this (standard for C# classes is upper case first letter, full names are also recommended, intellisense takes care of extra typing) :
public class Category {
public int Id { get; set; }
public int ParentId { get; set; }
public string Name { get; set; }
}
public class Item {
int Id ;
string Name;
string OtherItemProperties...
List<category> categories;
}
</category>
Now you can have any kind of tree structure between categories and subcategories, not just one category and one subcategory.