构造C#类的最佳方式

本文关键字：最佳 方式 构造 | 更新日期: 2023-09-27 18:20:32

我有以下类；

public class Hotel
{
   public int HotelId {get; set;}
   public string Name {get; set;}
   public string Address {get; set;}
   public string City{get; set;}
}
public class District
{
   public int DistrictId {get; set;}
   public string Name {get; set;}
}

然后我需要一个可以同时包含DistrictId和HotelId的类，所以我想创建一个类似的类

public class HotelDistrict
{
   public int DistrictId {get; set;}
   public int HotelId {get; set;}
}

这是正确的路吗？或者他们是更好的选择？

构造C#类的最佳方式

这看起来很像数据库表的设计。在OOP世界中，您通常会添加对类的引用，而不仅仅是对id的引用。

像这样的

public class HotelDistrict
{
   public Distric District {get; set;}
   public Hotel Hotel {get; set;}
}

没有什么灵丹妙药，所以这个规则也有例外，但通常情况下，您希望避免创建对数据库表来说味道太重的类。

酒店和地区有many to one relationship。因此，酒店应该有相应地区的地图-

public class Hotel
{
   public int HotelId {get; set;}
   public string Name {get; set;}
   public string Address {get; set;}
   public string City{get; set;}
   public int DistrictId{get; set;}
}

您可以简单地在Hotel中存储对District的引用，或者在District中存储List<Hotel>。通常情况下，除非您正在编写数据库模型，否则不应该像现在这样保留唯一标识符。如果这是一个数据库模型，那么假设您需要支持多个地区的酒店，那么您的解决方案就可以了。

无论出于何种原因，如果您真的需要使用原始的HotelDistrict方式，实际上不需要新的类，您只需要使用Tuple<Hotel, District>来存储对，并使用这些元组的列表（如List<Tuple<Hote, District>>）来存储这些对的列表。

但正如Rohit Vats所说，这是一种*1的关系，所以最好将该地区作为一个领域，所以如果你没有使用原始方法的具体原因，我建议你使用他的方法。

作为其他优秀答案的替代方案，如果您喜欢具有松散耦合对象的更显式的域模型，也可以执行以下操作。（我认为每一家酒店一次只能在一个地区。）

class Hotel
    int HotelId
    int DistrictId
    ...
class District
    int DistrictId
    ...
class HotelsInDistrict
    int DistrictId
    List<int> HotelIds

好处是：它是松散耦合的，你不需要摆弄巨大的对象图、懒惰/渴望加载之类的痛苦的东西。它沿着实际业务领域的路线，而不仅仅是数据容器。它是松散耦合的，可以很容易地进行修改。

缺点是：它不容易映射到您的t数据库表。但是，如果真正的对象模型只不过是一堆面向数据的"类"，而这些"类"只是表的表示，那么它就无法做到这一点。

也就是说，我真的向所有对物体建模感兴趣的人推荐一本书：

  • 流线型对象建模：模式、规则和实现
相关文章：