887 reputation
721
bio website
location
age
visits member for 2 years, 11 months
seen Apr 17 at 18:27

Nov
12
awarded  Popular Question
Oct
10
awarded  Popular Question
Sep
30
awarded  Popular Question
Aug
29
awarded  Favorite Question
Aug
2
comment Which layer does async code belong?
Yea, I'm aware how to marshall execution between threads. My question is whether or not we should be treating the operations as synchronous methods and letting the UI decide what to put on a background thread (what to execute asynchronously) or do we let the data layer dictate that the operation is asynchronous because we chose to implement the data layer asynchronously.
Aug
2
asked Which layer does async code belong?
May
19
awarded  Popular Question
May
10
awarded  Popular Question
Apr
27
awarded  Yearling
Apr
10
accepted Unit Testing in a “no setter” world
Mar
27
comment Unit Testing in a “no setter” world
This sounds like a complex implementation of the Memento pattern where you are storing the Memento in a file. I had thought about using that pattern but it seemed like a lot of extra work and duplicate code to implement. I agree with Peri that this solution seems fragile. I'm glad it works for you, but I'm not convinced at this point.
Mar
27
comment Unit Testing in a “no setter” world
So while that helps put the object into a valid initial state, testing the behavior of the object at it progresses through its lifecycle requires that the object be changed from its initial state. My OP has to do with testing these additional states when you can't simply set properties to change the object's state.
Mar
27
comment Unit Testing in a “no setter” world
Peter/Peri, I agree with both of you to some extent. I agree that it is useful, on occassion, to have constructor parameters to help define the initial state of my objects. However, as I said in my original comment, having parameters for each property becomes a problem as the size of the object increases. It also requires changes in 2 places if I want to add, remove or change a property (albeit in the same class). Bottom line for me is to have constructor parameters only for those properties and values that are required to put the object into a valid state. This is almost always a subset.
Mar
19
comment Unit Testing in a “no setter” world
We have a mix right now because of the free-range development I have been charged with wrangling in. Some ADO.NET using AutoMapper to hydrate from a DataReader, a couple of Linq-to-SQL models (that will be the next to replace) and some new EF models.
Mar
19
awarded  Nice Question
Mar
18
awarded  Nice Question
Mar
18
comment Unit Testing in a “no setter” world
I thought about this as a possible solution but hesitated to make my properties overridable or expose the setters as protected because it felt like I was opening the object up and breaking encapsulation. I think making the properties protected is certainly better than public or even internal/friend. I will definitely give this approach more thought. It's simple and effective. Sometimes that's the best approach. If anyone disagrees, please add comments with specifics.
Mar
18
comment Unit Testing in a “no setter” world
This does not scale well at all. My object could have many more properties with any number of them having or not having values at any given point in the object's lifecycle. I follow the principal that constructors contain parameters for properties that are required for the object to be in a valid initial state or dependencies an object requires to function. The purpose of the properties in the example are to capture the current state as the object is manipulated. Having a constructor with every property or overloads with different combinations is a huge smell and, as I said, doesn't scale.
Mar
18
comment Unit Testing in a “no setter” world
I share pdr's concern which is why I hesitated going this direction. Yes, it seems cleanest, but I don't like having multiple reasons an individual test can fail.
Mar
18
asked Unit Testing in a “no setter” world