Please forgive the cross-post to multiple forums. I did it
intentionally, but I *think* it was appropriate given the nature of my
question.

I'm working on an open source code library to help automate and clean
up parameter validation code. It's almost ready to go into open beta.
But one last little glitch is holding me up, and that would be the
name of the factory class that serves as the entry point into the
library: Validate.

Essentially, when you invoke the methods in this thing, your code
looks like this:

Validate.That(foo,
"foo").IsNotNull().StartsWith("bar").EndsWith("baz")

This works beautifully so far, but it becomes problematic when you use
it from ASP.NET pages, where a Validate method is already defined. As
you can imagine, the compiler thinks you're trying to invoke the
Validate method on the page; so invoking one of the That methods on
the Validate class (a factory) makes no sense.

You can get around it by using an alias with the namespace and change
to Verify or something:

using NValidate.Framework.Validate = Verify;

However, this creates a lot of manual work for the developer. It would
seem that the onus is on *me* as the publisher of the library to come
up with a solution. I mean, the whole POINT of this thing is to make
our lives easier.

So here's what I'm thinking: I could change the name of the Validate
class to Verify. That gets around the whole problem with ASP.NET
pages. That leaves only the following real concerns:

1.) Verify, like Validate before it, is a *very* common word. It's
likely that it will conflict with existing method names.

2.) The product name is NValidate. (Yep, just like NUnit, NCover,
NAnt, etc.) There might be a perceived disconnect between the product
name and the primary entry point into the library itself. (Validate
vs. Verify.)

3.) The classes that validate parameters are called validators. Again,
it's the same disconnect.

My questions for you folks with far greater experience than myself
are:

1.) Is the difference between the product name and the method name
that critical?

2.) Is there a better way to name the factory class?

I'm pretty desperate for input here as this is a one-man project so
far. Any help you big brained-folks can provide will be greatly
appreciated. For those who are interested, I can provide links to the
materials and the source code under development. (I won't spam the
boards--I'm not marketing something here. I'm trying to solve a
problem, and I don't know the best way to do it.)

Again, thanks for your help.

Anyone please tell me where to download NValidate?.

Mike Hofer wrote:
Show quoteHide quote

Anyone please tell me where to download NValidate?.

Mike Hofer wrote:
Show quoteHide quote

It's not available yet.

Look for the release announcement at :

http://www.nvalidate.org/





Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
Show quoteHide quote

It's not available yet.

Look for the release announcement at :

http://www.nvalidate.org/





Juan T. Llibre, asp.net MVP
asp.net faq : http://asp.net.do/faq/
foros de asp.net, en español : http://asp.net.do/foros/
======================================
Show quoteHide quote

On Oct 16, 9:48 am, Ngan Pham <nga***@matbao.com> wrote:
Show quoteHide quoteThe Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
BE PRODUCTION READY CODE. It's being released for public review.
However, since it's being released under the GPL, you're free to fix
any bugs you find and run with it.

Just don't expect to be able to sue me if it blows your foot off. :)

The web site's been expanded to include the API reference and
community forums. You can find them at http://www.nvalidate.org. Note
that the docs have some holes in them; they'll be fixed tonight as
well. (I'm posting this from work.)

Thank you for your interest!!

On Oct 16, 9:48 am, Ngan Pham <nga***@matbao.com> wrote:
Show quoteHide quoteThe Alpha Release of NValidate will be uploaded tonight. THIS WILL NOT
BE PRODUCTION READY CODE. It's being released for public review.
However, since it's being released under the GPL, you're free to fix
any bugs you find and run with it.

Just don't expect to be able to sue me if it blows your foot off. :)

The web site's been expanded to include the API reference and
community forums. You can find them at http://www.nvalidate.org. Note
that the docs have some holes in them; they'll be fixed tonight as
well. (I'm posting this from work.)

Thank you for your interest!!

On Oct 17, 4:00 pm, Mike Hofer <kchighl***@gmail.com> wrote:
Mike,

I downloaded it and gave it a brief test drive.  The API is pretty
much how I envisioned it would be.  I really like how similar the
"feel" is to NUnit's API.  I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation.  I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc.  I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

On Oct 17, 4:00 pm, Mike Hofer <kchighl***@gmail.com> wrote:
Mike,

I downloaded it and gave it a brief test drive.  The API is pretty
much how I envisioned it would be.  I really like how similar the
"feel" is to NUnit's API.  I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation.  I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc.  I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

On Oct 17, 4:00 pm, Mike Hofer <kchighl***@gmail.com> wrote:
Mike,

I downloaded it and gave it a brief test drive.  The API is pretty
much how I envisioned it would be.  I really like how similar the
"feel" is to NUnit's API.  I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation.  I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc.  I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

On Oct 17, 4:00 pm, Mike Hofer <kchighl***@gmail.com> wrote:
Mike,

I downloaded it and gave it a brief test drive.  The API is pretty
much how I envisioned it would be.  I really like how similar the
"feel" is to NUnit's API.  I think Demand is a great name for the
factory class and I'm actually glad that you decided against having
that ParamRule static class as portal to get to Demand.

You know...it's use cases might not just be limited to parameter
validation.  I'm thinking that it could be a complelling solution for
a lot of different things including Debug.Assert, user input
validation, etc.  I'm not sure how narrow of a scope you want to keep
for the project though.

Brian

Show quote Hide quote Thanks VERY much for downloading and test-driving the framework.

My goal in writing NValidate is to make it easier to write higher quality
software by writing less code without sacrificing clarity or significantly
impacting performance. (I would venture to say that that statement, in a
nutshell, summarizes the purpose of NValidate.)

If extending it to support additional validation outside of method and
property validation satisfies that rule, I'm game. But the scope of the
product must be reasonably constrained. There's another additional rule: The
end users should never be asked to use something that's so complex that they
can't reasonably explain it. If *we* can't explain what it's doing or how it
works, forget it. In my book, that's an unsafe operation. :)

Regarding the dropping of the ParamRule "domain": I'm very pleased that it
was dropped. It seemed unnecessary, and I simply couldn't justify it. It was
an entire class with one property on it:

public sealed class ParamRule
{
   public Demand Demand {
      get { return Demand; }
   }
   private ParamRule()
   {
   }
}

It seemed rather idiotic to me. Further, if you were going to do something
like that, you might as well have named it "I", and change Demand to Insist:

   I.Insist.That(dateOfBirth, "dateOfBirth").IsNotInFuture();

Now that's a truly fluent interface, but it's approaching the absurd, just
to satisfy OO purists. In the end, I decided to leave it out, and save the
overhead. I'm really happy with the way the API flows now, and aside from a
few known issues that I've got slated for resolution, I'm confident that
it's going to be a pretty decent product once it's finished.

I do have one concerned raised by a member on the NValidate forums. He's
concerned that creating lots of objects just to validate parameters might
negatively impact the application's performance. I was hoping you might
offer your opinion on that, now that you've had an opportunity to look at
it.

Before you do though, I'd like to offer the following points:

1. I specifically split the validators into two groups, derived from two
different base classes so that boxing and unboxing would not occur when the
value of a value type parameter was cached within the validator itself.
2. Only one validator is created per parameter. If the caller chains the
tests together (as intended), the same validator is reused over and over
again.
3. Each validator only holds two pieces of information: the name of the
parameter (a string), and the value of the parameter. So we're not keeping
lots of data in memory.
4. The validator's test method must conduct its test and either throw an
exception if the test fails or return a reference to the validator. The
tests are written to be as fast as possible. (If they're not written that
way, that's a defect and needs to be resolved.)
5. I avoided reflection and attribute-driven solutions because they tend to
be slower. (Reflection requires loading and parsing an assembly's manifest;
attribute-driven solutions require reflection.) The sole case where I use
reflection is in the IsValid test on the EnumValidator.

So those are the performance-measures I took when designing the framework. I
realize that we're going to have to just test the thing and measure the
impact and provide raw numbers at some point. But my gut feeling is that the
number and complexity of the objects were creating is so small compared to
the number and complexity of other objects created throughout the lifetime
of an application (or even within a method) that the impact will be minimal.
Again, I fully agree that testing must be done to prove this and fix it if
it's not true.

I do have a solution in mind if we think this will be a serious problem. I'd
just like to get a feel for whether or not it's worth redesigning the
framework or not.

Show quote Hide quote Thanks VERY much for downloading and test-driving the framework.

My goal in writing NValidate is to make it easier to write higher quality
software by writing less code without sacrificing clarity or significantly
impacting performance. (I would venture to say that that statement, in a
nutshell, summarizes the purpose of NValidate.)

If extending it to support additional validation outside of method and
property validation satisfies that rule, I'm game. But the scope of the
product must be reasonably constrained. There's another additional rule: The
end users should never be asked to use something that's so complex that they
can't reasonably explain it. If *we* can't explain what it's doing or how it
works, forget it. In my book, that's an unsafe operation. :)

Regarding the dropping of the ParamRule "domain": I'm very pleased that it
was dropped. It seemed unnecessary, and I simply couldn't justify it. It was
an entire class with one property on it:

public sealed class ParamRule
{
   public Demand Demand {
      get { return Demand; }
   }
   private ParamRule()
   {
   }
}

It seemed rather idiotic to me. Further, if you were going to do something
like that, you might as well have named it "I", and change Demand to Insist:

   I.Insist.That(dateOfBirth, "dateOfBirth").IsNotInFuture();

Now that's a truly fluent interface, but it's approaching the absurd, just
to satisfy OO purists. In the end, I decided to leave it out, and save the
overhead. I'm really happy with the way the API flows now, and aside from a
few known issues that I've got slated for resolution, I'm confident that
it's going to be a pretty decent product once it's finished.

I do have one concerned raised by a member on the NValidate forums. He's
concerned that creating lots of objects just to validate parameters might
negatively impact the application's performance. I was hoping you might
offer your opinion on that, now that you've had an opportunity to look at
it.

Before you do though, I'd like to offer the following points:

1. I specifically split the validators into two groups, derived from two
different base classes so that boxing and unboxing would not occur when the
value of a value type parameter was cached within the validator itself.
2. Only one validator is created per parameter. If the caller chains the
tests together (as intended), the same validator is reused over and over
again.
3. Each validator only holds two pieces of information: the name of the
parameter (a string), and the value of the parameter. So we're not keeping
lots of data in memory.
4. The validator's test method must conduct its test and either throw an
exception if the test fails or return a reference to the validator. The
tests are written to be as fast as possible. (If they're not written that
way, that's a defect and needs to be resolved.)
5. I avoided reflection and attribute-driven solutions because they tend to
be slower. (Reflection requires loading and parsing an assembly's manifest;
attribute-driven solutions require reflection.) The sole case where I use
reflection is in the IsValid test on the EnumValidator.

So those are the performance-measures I took when designing the framework. I
realize that we're going to have to just test the thing and measure the
impact and provide raw numbers at some point. But my gut feeling is that the
number and complexity of the objects were creating is so small compared to
the number and complexity of other objects created throughout the lifetime
of an application (or even within a method) that the impact will be minimal.
Again, I fully agree that testing must be done to prove this and fix it if
it's not true.

I do have a solution in mind if we think this will be a serious problem. I'd
just like to get a feel for whether or not it's worth redesigning the
framework or not.

I'm taking a short vacation this weekend so I'll follow up with a post
in a couple of days when I get more time.

I'm taking a short vacation this weekend so I'll follow up with a post
in a couple of days when I get more time.

I couldn't agree more.

Show quoteHide quoteTypically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with.  Furthermore, based on what you
just said, there's only one object per parameter.  So I agree that
object creation would be small relative to the rest of the developers
application.  The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.

Like you said, do some testing.  My hunch is that it won't be that big
of an issue.  Even if it is I'm sure there are more things that could
be done without redesigning the API.

I couldn't agree more.

Show quoteHide quoteTypically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with.  Furthermore, based on what you
just said, there's only one object per parameter.  So I agree that
object creation would be small relative to the rest of the developers
application.  The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.

Like you said, do some testing.  My hunch is that it won't be that big
of an issue.  Even if it is I'm sure there are more things that could
be done without redesigning the API.

I couldn't agree more.

Show quoteHide quoteTypically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with.  Furthermore, based on what you
just said, there's only one object per parameter.  So I agree that
object creation would be small relative to the rest of the developers
application.  The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.

Like you said, do some testing.  My hunch is that it won't be that big
of an issue.  Even if it is I'm sure there are more things that could
be done without redesigning the API.

I couldn't agree more.

Show quoteHide quoteTypically you would only do parameter validation on public methods
anyway so it's not like people are going to be littering their code
with calls to NValidate to begin with.  Furthermore, based on what you
just said, there's only one object per parameter.  So I agree that
object creation would be small relative to the rest of the developers
application.  The actual tests would have to be performed regardless
of whether someone is using NValidate or doing it manually so I don't
see any extra work going on there except for maybe the overhead of
calling the different methods which might actually be inlined in
several (most?) of the cases.

Like you said, do some testing.  My hunch is that it won't be that big
of an issue.  Even if it is I'm sure there are more things that could
be done without redesigning the API.

multiple references to only 1 object???
Whats needed for 3.0 apps
Help for a one year fresher to enter the software industry
Remoting - how to access server data?
Creating directories on Vista machines using .NET