Ayende @ Rahien

Phil commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Wed, 25 Jan 2012 23:22:11 GMT

+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.

Dan Turner commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Mon, 23 Jan 2012 05:58:08 GMT

constructs a view of a Customer*

Dan Turner commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Mon, 23 Jan 2012 05:57:25 GMT

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.

Dmitry commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Mon, 23 Jan 2012 04:46:06 GMT

@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.

Stan commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Sun, 22 Jan 2012 15:16:44 GMT

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.

Lord spa commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Sat, 21 Jan 2012 08:38:39 GMT

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.

Dan commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Fri, 20 Jan 2012 15:35:06 GMT

@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{ } Use something like: CustomerRepository : ICustomerRepository { GenericRepository r {get;set;} public Customer FindById(string id){ return r.FindById(id}; } Or am I missing your point?

dotnetchris commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Fri, 20 Jan 2012 14:48:58 GMT

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 commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Fri, 20 Jan 2012 14:33:16 GMT

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 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 { Public Customer FindById(string id) { return base.FindById(id) } } Or other noise abstractions. Or even entirely empty classes public CustomerRepository : GenericRepository { } ^ can't get any more anemic than that.

Rafal commented on Northwind Starter Kit Review: From start to finishing–tracing a request

Fri, 20 Jan 2012 10:04:12 GMT

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