The point is to increase the sales of your ORM profiler.

IMO, the inherent failure here is the dependency this author has taken: ICustomerRepository. ICustomerRepository then implements a generic repository through inheritance which is epic fail. Generic repositories only provide value if they're produced through composition, not inheritance.

If this code showed:

public CustomerDetailWindowWorkerServices(IRepository<Customer> customerRepository)

it would likely have far more value.

Completing repository implementations through inheritance is a gigantic anemic model problem. Leaving you with tons of useless classes like:

public CustomerRepository : GenericRepository<Customer> { Public Customer FindById(string id) { return base.FindById(id) } }

Or other noise abstractions. Or even entirely empty classes

public CustomerRepository : GenericRepository<Customer> { }

^ can't get any more anemic than that.

IMO, the inherent failure here is the dependency this author has taken: ICustomerRepository. ICustomerRepository then implements a generic repository through inheritance which is epic fail. Generic repositories only provide value if they're produced through composition, not inheritance.

If this code showed:

public CustomerDetailWindowWorkerServices(IRepository<Customer> customerRepository)

it would likely have far more value.

Completing repository implementations through inheritance is a gigantic anemic model problem. Leaving you with tons of useless classes like:

public CustomerRepository : GenericRepository<Customer> { Public Customer FindById(string id) { return base.FindById(id) } }

Or other noise abstractions. Or even entirely empty classes

public CustomerRepository : GenericRepository<Customer> { }

^ can't get any more anemic than that.

First post had all my generics butchered, hopefully this one works.

@dotnetchris

I like your assertion that "Generic repositories only provide value if they're produced through composition, not inheritance." I've seen this done many times before and never been comfortable with it.

Would you propose that, instead of

CustomerRepository : GenericRepository<Customer>{ }

Use something like:

CustomerRepository : ICustomerRepository { GenericRepository r {get;set;}

public Customer FindById(string id){ return r.FindById(id};

}

Or am I missing your point?

Despite many worthy views to the contrary I stick to lines of code at my favourite metric. It encourages the team to stop writing rubbish that others have to decipher and maintain, and to cut out layers of abstraction when they find them.

When your model is just a bag of properties and your application is just a CRUD you realy dont need repository. When you have complex model it is another story. It is a common case for commands when I should access one aggregate from other and than I prefer to inject repository into my entities instead of ISession. Just dont like to see NH use in a model. For queries I dont fetch model entities and than convert them to DTOs. I map DTOs to DB and directly use ISession in my query handlers.

@Stan

You are not supposed to have data access code (whether it is repositories or ADO .NET classes) inside entities. That is the whole point of the POCO concept.

So I'm guessing your problem is with the Repository and not the Service?

Because in my opinion that service performs a clear purpose, it constructs a view Customer. Admittedly it seems as though the service and view could have been named better. I am also more than happy to see code like this NOT happen in the body of a controller action for all but the most simplest of scenarios.

constructs a view of a Customer*

+1 to Dmitry. Having data access in your domain model is an absolute nightmare. Even though you can mock your DA interfaces it makes for way uglier tests.