如果我将所有属性放在一个模态类中会有什么缺点？ [英] What Are The Drawback If I Put All Properties In One Modal Class?

问题描述

在mvc中，我们通常根据我们的要求为不同的属性保留单独的类（如下所示）。现在我的问题是如果我将所有属性放在一个模态类中（如下所示）有什么缺点？

In mvc generally we keep separate class for different properties according to our requirement(as given below). now my question is what are the drawback if i put all properties in one modal class(as given below)?

public class category
{
public int CatId { get; set; }
public string CatName { get; set; }
}

public class subcategory
{
public int subcatId { get; set; }
public string catid { get; set; }
public string subcatname { get; set; }
}

public class item
{
public string itemid { get; set; }
public int catid { get; set; }
public string subcatid { get; set; }
public string item { get; set; }
}

===========所有属性====

=========== all properties ====

public class allitems
{

public string CatName { get; set; }
public string subcatname { get; set; }
public string itemid { get; set; }
public int catid { get; set; }
public string subcatid { get; set; }
public string item { get; set; }
}

推荐答案

以编程方式，当你需要编辑对象的某些部分时，你有更大的对象传递（例如作为基于类别ID的类别名称。



逻辑上，您有一个属性的blob而不是准确建模应用工作区的域对象。



这种特殊情况也显示了一些设计问题（但可能是一个要求，所以考虑到你自己的域名）：

- 你不应该有类别和子类别作为单独的对象（假设子类catid属性涉及父子关系） - 它们都是树中各种级别的类别

- item也可以有多个类别，因此您可以拥有List< category> ;类别;而不是单一类别（再次，取决于要求）

- 在项目中，由于亲子关系，单个类别ID将处理子类别和主要类别







相反（我会）创建这样的类别（C＃类的标准是大写的第一个字母，也建议使用全名， intellisense负责额外输入）：

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 {
/* since you're in a class named Category, you don't need property CategoryId, just Id suffices (this is personal preference so feel free to disregard this) :)
*/

    public int Id { get; set; }
    public int ParentId { get; set; }
    public string Name { get; set; }
}

public class Item {
/* since you're in a class named Item, you don't need property ItemId, just Id suffices (this is personal preference so feel free to disregard this) :)
*/
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.

问题是你不知道你的模型究竟是什么。鉴于所有视图都会看到所有属性，您不知道哪些属性将被填充并可供您使用。同样，如果您需要对模型进行更改，则很难知道哪些视图会受到影响。



这是假设您为所有视图使用单个模型。如果你实际上意味着一个特定的视图需要发送三个项目，那么为该视图创建一个具有每个项目作为属性的新模型没有任何内在错误。

The issue is that you don't know what your model actually is. Given all views see all properties you don't know which ones are going to be populated and available to you. Likewise if you need to make a change to your model it is harder to know which views are affected.

This is assuming you are using a single model for all your views. If you actually mean that one particular view needs three items sent to it then there is nothing inherently wrong with creating a new model for that view that has each of the items as a property.

这篇关于如果我将所有属性放在一个模态类中会有什么缺点？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！