假设我们有一个用 C# 表示的 SQL 表,如下所示:
public class Product
{
public int ID { get; set; }
public string Name { get; set; }
public string Picture { get; set; } // filename of the picture, e.g. apple.jpg
public int CategoryID { get; set; }
}
现在我们将查询数据库并检索对象,假设使用如下值:
ID = 1
Name = Yellow apple
Picture = apple.jpg
CategoryID = 25
一切都很正常。我现在正在思考的事情是:如果我想展示一个产品,我需要一些没有从数据库中查询到的附加信息,比如图像的确切文件路径,我们所拥有的只有
苹果.jpg
,但我们可能需要类似的东西
〜/图像/苹果.jpg
所以,我在想3种可能性:
1.) 向 Product 类添加一个新属性
public string PictureUrl
{
get
{
return "~/images/apple.jpg";
}
}
2.) 在执行表示逻辑期间指定完整的 url,比如说:
public void ShowProductDetails()
{
Product p = ProductRepo.GetProduct(id);
txtName.Text = p.Name;
imgPicture.ImageUrl = "~/images/" + p.Picture;
}
3.) 使用装饰器模式
第一种方法对我来说似乎是错误的(即使我已经使用了很长时间),因为我正在尝试使用分层的 Web 应用程序。我不确定硬编码这是一个好方法。
第二种方法更好,但更糟糕的是它不能轻易重用。如果我有多个地方在做同样的事情并且发生了一些变化,......如果我指定一些保存路径的静态常量,也许它会起作用......
第三种可能性在可维护性方面似乎相当复杂。我的班级数量可能要翻倍。如果我现在有 30 节课,它会突然变成 60 节:/
做这样的事情的最佳/推荐方式是什么?如果我向我的 POCO 添加不包含在 db 架构中的属性,我将无法使用 Dapper.Contrib 或 Rainbow 和类似的库,因为即使“选择”工作正常,我也无法“插入”或“删除”。我必须为每个命令硬编码 sql 字符串,这在一段时间后变得非常乏味,当你一直在做同样的事情时。
编辑:
Govind KamalaPrakash Malviya 的解决方案很棒,但不能每次都使用。我需要一种方法来解决任何类型的属性,即使是那些更复杂的属性 - 例如某些相册的照片数量。将照片的数量与相册一起查询是个好主意,但将其分配给什么?使用装饰器模式创建装饰类?
您如何解决此类架构问题?