501 reputation
36
bio website cpratt.co
location Houston, Texas, USA
age 31
visits member for 1 year, 9 months
seen Jul 10 at 1:40

Lead developer for the Museum of Fine Arts, Houston. Right now, I eat, sleep and breathe ASP.NET MVC, Web API, Entity Framework and Knockout.js.


Jun
23
awarded  Good Answer
Mar
27
comment Why shouldn't I use the repository pattern with Entity Framework?
@TheZenker, you may not have been exactly following the repository pattern. The strictest difference is the return value. Repositories return queryables, whereas services should return enumerables. Even that's not really that black and white, as there's some overlap there. It's more in how you use it. A repository should just return the set of all objects, which you then further query into, while the service should return the final dataset, and should not support further querying.
Mar
6
comment Why shouldn't I use the repository pattern with Entity Framework?
EF's testability has improved greatly in version 6. You may now fully mock DbContext. Regardless, you could always mock DbSet, and that's the meat of Entity Framework, anyways. DbContext is little more than a class to house your DbSet properties (repositories) in one location (unit of work), especially in a unit testing context, where all the database initialization and connection stuff is not wanted or needed anyways.
Mar
6
comment Why shouldn't I use the repository pattern with Entity Framework?
You can mock DbContext in EF6+ (see: msdn.microsoft.com/en-us/data/dn314429.aspx). Even in lesser versions, you can use a fake DbContext-like class with mocked DbSets, since DbSet implements an iterface, IDbSet.
Mar
5
awarded  Nice Answer
Feb
5
answered ASP.NET MVC SoC when dealing with back end objects (design decision)
Jan
16
awarded  Necromancer
Dec
23
awarded  Yearling
Dec
3
answered Why shouldn't I use the repository pattern with Entity Framework?
Apr
8
awarded  Scholar
Apr
8
comment Separation of Concerns While Creating a Generic Concept of a “Cart Item”
Thanks for the suggestion of using an interface. I'm relatively new to the world of strongly-typed languages. (I've spent most of my career working with duck-typed languages like Python and Ruby.) I know about interfaces, but they always escape my planning for some reason.
Apr
8
accepted Separation of Concerns While Creating a Generic Concept of a “Cart Item”
Apr
8
comment Separation of Concerns While Creating a Generic Concept of a “Cart Item”
I'm giving you the credit on this one because I think your answer is the closest to the actual implementation I'll end up following. An interface is a great idea, of course, but I like the idea of having a factory that sort of abstracts away the responsibility. All the products need not worry about how they are added to the cart, and the cart need not worry about how products are added to it. Instead, a specialized class(es) take care of this translation.
Apr
8
awarded  Supporter
Apr
8
comment Separation of Concerns While Creating a Generic Concept of a “Cart Item”
Good point. You're right. Just because a model changes, doesn't necessarily mean the factory method must change, as long as the constructor itself hasn't changed.
Apr
6
awarded  Student
Apr
6
asked Separation of Concerns While Creating a Generic Concept of a “Cart Item”
Sep
24
comment How can I really master a programming language?
Languages do in fact evolve. Dead languages do not, obviously, because they are dead. Relatively "mature" languages evolve less, perhaps, but just look at the myriad of changes that have occurred in languages such as Objective-C, Python, Ruby, JavaScript, etc. over the last few years alone.
Sep
19
awarded  Teacher
Sep
19
awarded  Autobiographer