new ThoughtStream("Derick Bailey"); - All Comments

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

jOE — Thu, 18 Mar 2010 04:28:28 GMT

1) Does the current solution work?

2) Why not use full-text to find product codes? Drop downs are evil.

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

Diego — Wed, 17 Mar 2010 18:16:59 GMT

I don't have the same concern as you. Passing null back to the listener of the event is better approach. It's safe in the language, it's semantics really means "nothing", it's easy to check, it's lightweight (costs an clean IntPtr).

Why would you think the user HAS to know something which he might not know. I think is way more straight to work with null than with empty object (null pattern).

BUT, if still you're not comfortable passing a null back on Selection event, maybe you could take a look at option construct on F#. Maybe you can have something like this in C#.

re: When Do You Specify Expected Parameters In Stub Methods?

Bill Sorensen — Wed, 17 Mar 2010 18:09:16 GMT

I'd specify the argument but use a constant in this case.

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

derick.bailey — Wed, 17 Mar 2010 17:30:37 GMT

@Dan, @Dennis,

The null object pattern would be a better OO solution, but wouldn't solve the modeling problem, which is the real problem that I'm trying to address. I do like the null object pattern, though. it solves a lot of OO problems.

@Keith,

an undo of hte command would require a memento pattern as well, but would certainly be a possibility, technically. though in this case, i think it would be overkill. i really don't need an n-level undo and i'm not really dealing with a command at this point. it really is an event - something has happened and the parent form needs to respond - and not a command - something needs to happen, go do it for me.

@rob,

a single Change event would be a better option for #1. good suggestion on that one.

as for the parent and subscribing to two events... the parent will handle either event as distinct things to respond to. the parent cannot assume either of them firing first or second, or having them fired only once. the parent has to be able to respond to any number of either event as they occur. the good news is that it is far easier to code like this than to assume or expect a certain order for the events.

re: Semantic Code: Migrating From A Chatty Interface To A Simple One With A Data Transfer Object

Szilard Birkas — Wed, 17 Mar 2010 16:10:36 GMT

As I see the original interface would have based on Command Pattern, sg similar:

interface ICommand { void Run(); }

interface IMyCommand: ICommand

{

string InputValueX{ get; set; }

string OutputParameterX { get; private set; }

}

If this command pattern would be used in a system in a good way, then it is ok.

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

Dennis Doomen — Wed, 17 Mar 2010 15:48:13 GMT

What about using the Null Pattern. You surely need the the rest of the product's info as well. So maybe you can add a public readonly property called Null that returns a special instance of your view model that represents 'nothing selected'.

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

Keith Bloom — Wed, 17 Mar 2010 15:34:38 GMT

An explicit event must be simpler, otherwise the selection event will be the selection event with a status to specify if it is a de-selection event, which doesn't sound good.

I have recently read the GOF book and the patterns are running around in my head trying to find a place in some code. I am curious to know if a Command object would work here which has the ability to undo the Command issued. Do you know if this is a common use of the pattern?

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

Dan — Wed, 17 Mar 2010 15:14:25 GMT

I'm leaning towards option #2 as well...but have you considered using the Null Object Pattern in your original scenario?

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

Rob — Wed, 17 Mar 2010 15:10:21 GMT

Try thinking about it from the parent side - what interface would you want.

Having two events leaves questions like do I get a deslect event before every select event, to indicate the deselection of the previous event.

I would go for a single event called Change. Then either in the event args or exposed as properties of the control (Sender), you have the "get selected item" / "is there a selected item" logic.

re: Application Events: Modeling Selection vs De-Selection as Separate Events?

Jason Meckley — Wed, 17 Mar 2010 15:03:40 GMT

I would go with option 2 as well. you already have event aggregation in place. separating the concerns of "selected" & "de-selected" makes sense.

Side Projects, Community Involvement, Etc.

new ThoughtStream("Derick Bailey"); — Tue, 16 Mar 2010 16:03:40 GMT

There was some interesting discussion amongst LosTechies members recently, and one of the things that

DotNET News

DotNET News — Tue, 16 Mar 2010 15:10:52 GMT

DotNET News

DotNET News — Tue, 16 Mar 2010 15:10:50 GMT

DotNET News

re: A Type Safe IDataReader Wrapper

Jason — Tue, 16 Mar 2010 14:48:46 GMT

I posted something similar on my blog just a few months ago ... its an extension method and also deals with nullables.

/// <summary>

/// Get the value of a table column from a reader object

/// </summary>

/// <typeparam name="T">Type of expected return value</typeparam>

/// <param name="reader">Reader oject to get the value from</param>

/// <param name="columnName">Name of column to retrieve the value from</param>

/// <returns>Column Value</returns>

/// <exception cref="NullReferenceException">If T is not nullable and the column value is null</exception>

public static T GetColumnValue<T>(this IDataReader reader, string columnName)

{

if (reader.IsDBNull(reader.GetOrdinal(columnName)))

{

if (

(typeof(T).IsGenericType && typeof(T).GetGenericTypeDefinition() == typeof(Nullable<>))

|| typeof(T) == typeof(string)

)

{

return default(T);

}

else throw new NullReferenceException("DB Value is null");

}

else return (T)reader[columnName];

}

re: A Type Safe IDataReader Wrapper

derick.bailey — Tue, 16 Mar 2010 13:16:06 GMT

@travis,

we have something similar to fluent ado... not quite as full featured, but it suits our needs quite nicely.

@steve,

I'm not trying to encapsulate the the data reader, entirely - that's why i'm not implementing IDataReader for this object. I'm going to convert this to extension methods, too, as @jeff suggested.

i like the caching idea for the name lookups! that will definitely help for large data sets (which we have)