C#中的泛型和约定

Question

我有一个.NET服务层的接口,它反过来将通过Web服务与第三方系统通信.这可以处理与第三方系统功能相关的许多不同任务(它实际上是一个定制的CRM系统,但由于上下文不相关,我会将其换成一些微不足道的东西).

界面看起来像这样:

public interface IMyService
{
    CarModel GetCar(string registration);
    CarModel AddCar(Car car);
    PersonModel GetPerson(string personId);
    PersonModel AddPerson(Person person);
}

现在,我的模型目前的工作方式如下:我有一个BaseResponseModel,每个都SomethingModel继承.每个SomethingModel包含一些基本属性,也包含一个Something- 像这样:

基础响应模型

public class BaseResponseModel
{
    public List<string> Errors { get; set; }
    public bool HasErrors
    {
        get
        {
            return (Errors != null && Errors.Count > 0);
        }
    }
}

具体的反应模型

public class CarModel : BaseResponseModel
{
    public Car Car { get; set; }
}

public class PersonModel : BaseResponseModel
{
    public Person Person { get; set; }
}

在这里,Car并且Person只包含了一堆的公共属性.然后,我的每个方法都IMyService接受其参数,将请求格式化为.asmx Web服务,将响应解析为其响应模型并将其返回给调用者(.ascx代码隐藏).

但是,不同...Model类的数量(更不用说它们的包装对象都有不同的属性名称)变得很难看.我想按照以下方式做一些事情:

public class Car
{
    public string Registration { get; set; }
}

public class ServiceResponse<T>
{
    public List<string> Errors { get; set; }
    public bool HasErrors { ... }
    public T Result { get; set; }
}

public interface IMyService
{
    ServiceResponse<Car> GetCar(string registration);
    ServiceResponse<Car> AddCar(Car car);
    ServiceResponse<Person> GetPerson(string id);
    ServiceResponse<Person> AddPerson(Person person);
}

然后,我的ASP.NET控件ServiceResponse<T>将从中的每个方法接收IMyService.

这是C#中泛型的"常规正确"用法吗？或者这是否只是掩盖了我的解决方案中更深层次的架构缺陷？我提出的解决方案是否缺少某些东西(尽管注意到不同的方法Get和Add方法的实现并不像原型那样通用)？

_{^{免责声明:如果这个问题"过于主观",请道歉,但对于Programmers.SE而言,它似乎太具体而不是一个理论问题,而且对于CodeReview.SE来说有点过于通用.如有必要,我愿意就如何改进问题提出建议.}}

Answer 1

我不认为使用泛型有什么问题，除非有人可能从 .NET 以外的其他地方使用您的服务。我认为它为 WSDL 生成了相当丑陋的合约名称。

因此，对于您的用例，我认为这很好。我很高兴你也从Model改为。Response我本来打算这么建议的。

根据错误的使用方式，我个人更愿意为它们引发（聚合）异常。但是，如果您将它用于表单验证或其他用途，我会说这是可以接受的。