¿Por qué el patrón de repositorio se utiliza ampliamente en el marco de la entidad como si fuera complejo?

Un registro de mis problemas

estoy creando un proyecto de demostración que contiene operaciones de CRUD usando patrones de repositorio e inyección de dependencias.
Esta es mi estructura:
Método 1 (muy popular, utilizado por muchos desarrolladores)
Mi interfaz de repositorio:
public partial interface IRepository<T>
{
    void Insert(T entity);
}
Mi nivel de servicio:
public partial interface IEmployeeService
{
    void InsertCategory(EmployeeMaster employeeMaster);
}
Mi clase implementará esta interfaz (Servicio):
public partial class EmployeeService : IEmployeeService
{
    private readonly IRepository<EmployeeMaster> _employeeMasterRepository;

    public EmployeeService(IRepository<EmployeeMaster> employeeMasterRepository)
    {
         this._employeeMasterRepository = employeeMasterRepository;
    }

   public virtual void InsertCategory(EmployeeMaster employeeMaster)
   {
        _employeeMasterRepository.Insert(employeeMaster);
   } 
Este es mi controlador:
public class HomeController : Controller
{
        private readonly IEmployeeService  _employeeService;

        public HomeController(IEmployeeService employeeService)
        {
            this._employeeService = employeeService;
        }
Esta es la estructura que seguí en el proyecto comercial Nop (http://www.nopcommerce.com), que creo que la mayoría de los desarrolladores siguen ahora, es decir, el patrón de repositorio y la inyección de dependencia.
He hecho esto antes, como crear un proyecto Bal (Business Access Layer) en mi aplicación, y luego crear un archivo de clase en Bal, y hacer la siguiente inserción:
Método 2:
public class MyBal()
{
    public void Insert()
    {
        using (MyEntities context = new MyEntities ())
        {
            var result = context.MyTable.Add(_MyTable);
            context.SaveChanges();
            return result;
        }
}
A continuación, llame a este método directamente desde mi aplicación MVC, como sigue:
[HttpPost]
public ActionResult Insert(Model M)
{
    MyBal bal = new MyBal ();
    bal.Insert();
}
¿Entonces, por qué la mayoría de los desarrolladores siguen creando una estructura tan compleja, el patrón de repositorio? ¿Alguien puede explicar la diferencia entre el método 1 y el método 2?
Si el método 1 mejora el rendimiento o simplemente se refiere a la separación del Código o a una mejor mantenibilidad del Código.

Tal vez la mejor solución

muchas personas implementan un repositorio en el marco de la entidad, que utiliza el patrón del repositorio. Hay algunos cambios en el razonamiento detrás de esto; La decisión de si una de ellas es razonable es una cuestión de opinión.
Esto es lo que Microsoft demostró en su serie de tutoriales Part 9 of 10. Debido a que Microsoft ha demostrado este patrón, es ampliamente considerado un enfoque razonable.
  • está separado del marco de entidad. La idea es que si eligen reemplazar el marco de entidad, pueden cambiar el repositorio sin modificar otra lógica de negocio. En la práctica, sin embargo, usted realmente debe trabajar en una tecnología, y la separación correcta de la lógica del marco de entidad requiere mucho trabajo. Por último, es probable que encuentre métodos en su repositorio que existen porque es una forma eficaz de trabajar, por lo que cambiar a otro orm todavía afecta a su entidad de negocio.
  • genérico. La combinación de genéricos y patrones de repositorio es una práctica común que minimiza la duplicación de código. La idea es que si usted tiene cientos de clases para realizar operaciones CRUD, el repositorio genérico será más unificado y fácil de mantener, pero puede ser un poco menos flexible.
  • es fácil de integrar con la herramienta de inyección de dependencias. En algunos casos, puede ser más fácil utilizar la herramienta de inyección de dependencias utilizando el modo repositorio.
  • Prueba de unidad
  • . Esto es consistente con el punto 4, donde el modo repositorio le proporciona una clase unificada que puede ser fácilmente simulada para pruebas unitarias.
  • No es una List a exhaustiva de razones por las que no estoy de acuerdo con cada punto tanto como estoy de acuerdo con ellos, pero esta es mi observación del proceso de pensamiento alrededor de este patrón en particular.
    En cuanto a su segunda pregunta, la diferencia entre dos ejemplos... En el primer caso, usted crea un servicio y un repositorio que puede existir en un proyecto o espacio de nombres completamente diferente de su entidad de negocio. Su entidad comercial no conoce ni se preocupa por el marco de la entidad. Si necesita cambiar la forma en que funciona el repositorio, debe tener poco impacto en su entidad, que funciona de la misma manera que antes.
    En el segundo caso, se enlaza directamente al marco de entidad. Esto, as í como cualquier otra entidad comercial, debe conocer el marco de la entidad, y cualquier cambio en el marco de la entidad puede significar un cambio en el Código en esa entidad o en cualquier otra entidad similar. Puede ser un proceso muy largo para muchas entidades. Además, no puede probar fácilmente la entidad porque cualquier prueba que realice causará que se escriba en la base de datos.