Question

我正在处理一个非常大的项目，其服务层当前在许多服务类中进行组织，这些服务类包含每个数据库实体的CRUD操作。例如，对于实体“产品”，我们有：

public class ProductService
{
    public bool AddProduct(Product product)
    {
        // code omitted
    }

    public bool DeleteProduct(Guid productId)
    {
        // code omitted
    }
}

对于实体“用户”：

public class UserService
{
    public bool AddUser(User user)
    {
        // code omitted
    }

    public bool DeleteUser(Guid userId)
    {
        // code omitted
    }
}

现在，想象一下有这样的几十个实体，都有自己的服务。每次你想操纵它们时，你都必须实例化所有需要的服务，所以你的代码总是以这样的方式开始：

var productService = new ProductService(); 
var userService = new userService(); 

productService.AddProduct();
userService.AddUser();

对我而言，这看起来不必要一个混乱，所以我想：为什么不只有一个包含所有服务方法的类，可能在部分类中拆分以保持组织有效？结果将是：

public partial class MyService
{
    public bool AddProduct(Product product)
    {
        // code omitted
    }

    public bool DeleteProduct(Guid productId)
    {
        // code omitted
    }
}

public partial class MyService
{
    public bool AddUser(User user)
    {
        // code omitted
    }

    public bool DeleteUser(Guid userId)
    {
        // code omitted
    }
}

用法：

var service = new MyService();

service.AddProduct();
service.AddUser();

你觉得这种做法有什么缺点吗？我有什么理由不这样做吗？

Answer 1

您提供的此代码似乎是对DDD的尝试。

我建议你做的是阅读CQRS，然后实现一个Handler类来处理一般的Query<T>类。

Query<T>可以负责创建必要的DbContext和Getting数据。

同样，对于Add等，您将拥有Command<T>类。

关键在于代码将非常小，但所有常见部分都将留在泛型类中，从而导致高代码重用和可维护性。

其次，在现代.Net中（除非您使用Xamarin），不应在任何代码中编写var x = new Service()。阅读依赖注入（控制反转，IoC）。这种模式适用于.Net（WPF，ASP .Net，UWP，WinRT等）的大多数主要平台，并将大大提高代码的可测试性。

我应该在部分类中组织我的实体框架服务层吗？

1 个答案: