Должен ли я организовывать свой сервисный уровень Entity Framework в частичных классах?

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() в любом коде. Читайте об инъекции зависимостей (Inversion of Control, IoC). Этот шаблон доступен для большинства основных платформ для .Net (WPF, ASP .Net, UWP, WinRT и т. Д.) И значительно улучшит тестируемость кода.