Hey Rocky!
Some of us have created classes emulating SmartDate for other datatypes (such as SmartInt16, SmartInt32, SmartInt64, SmartFloat, SmartBool, etc.).
I've created an interface to assign to all the locally created Smart structs. It's called ISmartField.
It makes it much easier (for me at least!) to write generic rule libraries that deal with all the different Smart fields.
It would be really nice if the ISmartField interface was added to CSLA and SmartDate implemented it.
The interface doesn't actually have to do anything - it just lets us know we can common Smart struc methods like Parse, DBValue, etc.
I know it's possible to do this other ways, but this seems to be a really pragmatic, productive way to do this. (Of course, maybe I just need to learn yet another new trick.)
using System;
using System.Collections.Generic;
using System.Text;
namespace
Csla/// <summary>
}
What do others think?
What need have you found for SmartInt32 that isn't solved by the .NET framework's nullable int?
I have found them adequate and quite useful, especially with the null-aware DevExpress input controls. I haven't seen a need to even use SmartDate any more.
Brian, was your question to me?
If so, I don't know what you mean. All that max/min date stuff in SmartDate was created to solve the problem of DateTime being a value type, and therefore not nullable, which means there was no way to preserve a true null from the database into the BO and back to the database.
DateTime? accomplishes exactly that.
What more is necessary?
Brian Criswell:
The classic example is sorting start dates vs sorting end dates. For start dates a null start date would be early than a filled in start date. This would fit in with how I understand DateTime? to sort. However, for end dates you would want a null end date to be later than a filled in end date. How would this work?
Exactly! Having a class that treats an empty value as the lowest or highest possible value is incredibly handy. That's one of the two reasons I want SmartInt16, SmartDecimal, etc. I sometimes need to deal with the same problem in those data types.
The other reason has to do with mental bandwidth. I have enough to learn as it is. Consistently using SmartDates (etc.) for nulls and for min/max handling is simpler because it is one less thing to have to learn just to get a program out the door. :) And that learning curve has to be paid by every programmer on the team, so reducing learning curve costs is important.
Interesting. One of the reasons I prefer using the DateTime? instead of the SmartDate is because of the learning curve issue, which is approximately nothing in my case IMO.
The sorting issue has not bit me, but that's probably because many of the DevExpress tools seem to have their own sortable wrapper functionality, and I haven't had a specific case of needing to sort a list will nulls.
Good knowledge to have though. Thanks for esplainin' Lucy.
Actually I think the reason would be because you can handle user input as string and can set the format of the output all in the business objects using a factory object. This saves from having to set it in the UI code. You also can allow the user to enter in codes like 'm' for Integer.MaxValue or 'mi' for Integer.MaxValue and could then change thing to the integer values. Date time can take advantage of this more adding âtâ for today, 'y' for yesterday, etc... Also if you had a Float and Double one you could set the format as well which could help out a lot! I only wish Rocky would have written a Smart Field for each value type. It would have saved us time on writing them ourselves. I also wrote my own interface for it and for smart date ended up using copy paste inheritance.
I have debated on refactoring it using Nullable(Of Type) and just writing the convert from and to logic into a shared class. This seems more logical to me then maintaining all these structures, especially now that Nullables are full blown in VB.net 9.0.
I did add the ISmartField interface in 3.5.
I also radically enhanced SmartDate with some type conversion capabilities that make it much nicer to work with. But if you look at the code, it totals up to quite a lot - so I'm sure not looking to wrap every primitive .NET type in a class like that ![Smile [:)]](/emoticons/emotion-1.gif)
Copyright (c) Marimer LLC