域模型中的继承与枚举属性 [英] Inheritance vs enum properties in the domain model

问题描述

我在工作中讨论过领域模式继承使开发人员生活变得复杂。我是一个OO程序员，所以我开始寻找在领域模型中继承的论据，实际上可以缓解开发人员的生活，而不是在所有地方使用开关。

什么我想看看是这样的：

  class Animal {
 
} 
 
 class Cat：Animal {
 
} 
 
 class Dog：Animal {
 
} 
  / pre> 
 
 
另一位同事说的是：
  public枚举AnimalType {
未知，
猫，
狗
} 
 
 public class Animal {
 
 public AnimalType Type {get ;组; } 
 
} 
  
我如何说服他（链接 WELCOME ），类层次结构比在这种情况下拥有枚举属性更好？
 
 
 
谢谢！
解决方案
这是我如何理解的：
 
 
 
只有当角色/类型永远不会改变时才使用继承。 
例如
 
 
 
使用继承，例如：
 
 
 
消防员<  - 员工<  - 人错了。只要弗雷迪，消防员改变工作或失业，你必须杀死他，并重新创建一个新的对象，并附上所有旧的关系。 / p> 
 
 
所以，上述问题的天真解决方案是给Person类赋予JobTitle枚举属性。 
这在某些情况下是足够的，例如如果您不需要与角色/类型相关联的非常复杂的行为。
 
 
 
更正确的方法是给人类列表角色。 
每个角色代表例如具有时间跨度的就业。
 
 
 
例如
 code> freddy.Roles.Add（new Employement（employmentDate，jobTitle））; 
  
或者如果这是超额的：
  freddy.CurrentEmployment = new Employement（employmentDate，jobTitle）; 
  
这样，Freddy可以成为一名开发人员，我们必须先杀死他。 > 
 
 
但是，如果您应该为jobtitle使用枚举或类型层次结构，我所有的漫游仍然没有回答。
 
 
 
在我的mem OO中，我会说，在这里使用继承的工作更正确。
 
 
 
但是，如果你正在做O / R映射，你可能会得到如果映射器尝试将每个子类型映射到一个新表，那么幕后的一些过于复杂的数据模型。 
所以在这种情况下，如果没有与类型相关联的真实/复杂的行为，我经常去枚举方法。 
如果用法有限，我可以使用if type == JobTitles.Fireman ...，这样可以使事情变得更简单或更小。
 
 
 
例如.NET的Entity Framework 4设计器只能将每个子类型映射到一个新的表。当您查询您的数据库时，您可能会遇到一个丑陋的模型或许多联接。任何真正的好处。
 
 
 
但是，如果类型/角色是静态的，我确实使用继承。 
例如对于产品。
 
 
 
您可能有CD<  - 产品和图书<  -   - 产品。 
继承在这里获胜，因为在这种情况下，你很可能有不同的状态与类型相关联。 
 CD可能有一些磁道属性，而一本书可能具有页数属性。
 
 
 
所以简而言之，它取决于： - ）
 
 
 
另外，在最后一天，你最有可能最终会有很多switch语句。 
假设你想编辑一个产品，即使你使用继承，你可能会有这样的代码：
 
 
 
 if（product is Book） 
 Response.Redicted（〜/ EditBook.aspx？id+ product.id）; 
 
 
 
由于编辑实体类中的编辑书本URL将为简单的丑陋，因为这将迫使您的商业活动了解您的网站结构等。
 
I had a discussion at work regarding "Inheritance in domain model is complicating developers life". I'm an OO programmer so I started to look for arguments that having inheritance in domain model will ease the developer life actually instead of having switches all over the place.

What I would like to see is this :
class Animal {

}

class Cat : Animal {

}

class Dog : Animal {

}
What the other colleague is saying is :
public enum AnimalType {
    Unknown,
    Cat,
    Dog
}

public class Animal {

    public AnimalType Type { get; set; }

}
How do I convince him (links are WELCOME ) that a class hierarchy would be better than having a enum property for this kind of situations?

Thanks!
解决方案
Here is how I reason about it:

Only use inheritance if the role/type will never change.
e.g. 

using inheritance for things like:

Fireman <- Employee <- Person is wrong.

as soon as Freddy the fireman changes job or becomes unemployed, you have to kill him and recreate a new object of the new type with all of the old relations attached to it.

So the naive solution to the above problem would be to give a JobTitle enum property to the person class.
This can be enough in some scenarios, e.g. if you don't need very complex behaviors associated with the role/type.

The more correct way would be to give the person class a list of roles.
Each role represents e.g an employment with a time span.

e.g.
freddy.Roles.Add(new Employement( employmentDate, jobTitle ));
or if that is overkill:
freddy.CurrentEmployment = new Employement( employmentDate, jobTitle );
This way , Freddy can become a developer w/o we having to kill him first.

However, all my ramblings still haven't answered if you should use an enum or type hierarchy for the jobtitle.

In pure in mem OO I'd say that it's more correct to use inheritance for the jobtitles here.

But if you are doing O/R mapping you might end up with a bit overcomplex data model behind the scenes if the mapper tries to map each sub type to a new table.
So in such cases, I often go for the enum approach if there is no real/complex behavior associated with the types.
I can live with a "if type == JobTitles.Fireman ..." if the usage is limited and it makes things easer or less complex.

e.g. the Entity Framework 4 designer for .NET can only map each sub type to a new table. and you might get an ugly model or alot of joins when you query your database w/o any real benefit.

However I do use inheritance if the type/role is static.
e.g. for Products.

you might have CD <- Product  and Book <- Product.
Inheritance wins here because in this case you most likely have different state associated with the types.
CD might have a number of tracks property while a book might have number of pages property.

So in short, it depends ;-)

Also, at the end of the day you will most likely end up with a lot of switch statements either way.
Let's say you want to edit a "Product" , even if you use inheritance, you will probably have code like this:

if (product is Book)
        Response.Redicted("~/EditBook.aspx?id" + product.id);

Because encoding the edit book url in the entity class would be plain ugly since it would force your business entites to know about your site structure etc.

                        
这篇关于域模型中的继承与枚举属性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！