Question: Does anyone use the non-generic DataPortal methods?

Old forum URL: forums.lhotka.net/forums/t/7893.aspx

RockfordLhotka posted on Wednesday, October 28, 2009

For some time now the data portal has had generic and non-generic methods:

DataPortal.Fetch()

DataPortal.Fetch<T>()

I am curious as to whether anyone still uses the non-generic methods?

I ask, because it would simplify life if I could get rid of them, and I'm considering eliminating them in version 4.0. But if there are sound reasons to have them I'd like to know.

cdkisa replied on Wednesday, October 28, 2009

I only use generics. My vote: simplify your life!

fussion_am replied on Wednesday, October 28, 2009

I have not used the non-generic version for quite sometime. I too vote to simplify.

chrisghardwick replied on Wednesday, October 28, 2009

I think it would be time to upgrade your library if your still using the non-generic dataportal methods.

JoeFallon1 replied on Wednesday, October 28, 2009

I use the generic methods only.

rxelizondo replied on Wednesday, October 28, 2009

I vote for removal too.

And if you happen to feel inspired, don’t hesitate to remove just about everything else that you feel would simplify the CSLA. You have my 10000000% support.

Fintanv replied on Wednesday, October 28, 2009

I use the generic methods only. You have my vote to remove them.

ajj3085 replied on Wednesday, October 28, 2009

Don't think I use non-generic calls either. Slightly off topic, but do you use the Obsolete attribute, or find it unnessary?

chrduf replied on Wednesday, October 28, 2009

You have my vote to remove them. It is very easy to migrate to the new syntax.

Marjon1 replied on Wednesday, October 28, 2009

I'm not using them, so removing them is alright by me.

rxelizondo replied on Wednesday, October 28, 2009

I was just thinking about this post and could not help but wonder, if we are going to go ahead and remove support for non generic data portals (which I agree with 100%), why not remove support for the other non generic features too. Why not clean up while we have the patient open?

For example, page 351 of the book:
Note: It might seem like the RuleArgs parameter should just be of type DecoratedRuleArgs or MaxLengthRuleArgs, using the generic RuleHandler delegate. That would be ideal, but it would break backward compatibility with older versions of CLSA .NET, so I’ve chosen to take the approach shown here.

Just search the e-book for the text “backward compatibility” and fix the CSLA so that you don’t have to used that word in the book ever again :)

Man, I am sure that sooner or later someone is going to curse at me for ranting about this all the time. Sorry guys, that’s just the way I am!

RockfordLhotka replied on Wednesday, October 28, 2009

One step at a time. I have other things I want to discuss regarding the business/validation rules subsystem - that'll be another thread (or two).

mbblum replied on Wednesday, October 28, 2009

I'm in the process of updating our objects to 3.8 over the next couple months. If I find any, they will get changed to generics.

Make the change is my recommendation. While it is "breaking" if not already being used, it is a relatively easy and desirable change to make during an upgrade.

skagen00 replied on Wednesday, October 28, 2009

No non-generic usage here either.

RockfordLhotka replied on Wednesday, October 28, 2009

> No generic usage here either.

No generic, or no non-generic?

skagen00 replied on Thursday, October 29, 2009

No non-generic use - I corrected my post right after I misspoke but it was too late to stop the generated e-mails :)

JonnyBee replied on Thursday, October 29, 2009

Hi,

We should only use the generic versions too but somtimes it is hard to tell if it is the generic or non-generic methd that is chosen by the compiler.

Example from the ProjectTracker.Library.Project.cs class ExistsCommand:
ExistsCommand result = null;
result = DataPortal.Execute(new ExistsCommand(id));

The compiler chooses the generic version even if the code does not explicitly say generic.

How about adding an Obsolete attribute and message "Change to ....., will be removed in Csla 4.0" on the non generic methods in DataPortal (and others that you will probably remove) .

RockfordLhotka replied on Thursday, October 29, 2009

Given the questions about the Obsolete attribute, I should maybe explain my plan.

My plan is to eliminate the need for the criteria object to contain the target object type. So you do this:

return DataPortal.Fetch<CustomerEdit>(new SingleCriteria<int>(id));

Ideally I’ll derive a scheme where SingleCriteria isn’t necessary either:

return DataPortal.Fetch<CustomerEdit>(id);

Obviously the type of business object is critically important, so it must be available – and it is through the type parameter. Which means the non-generic methods would either entirely go away, or at best their method signatures would change to include a type parameter:

return DataPortal.Fetch(typeof(CustomerEdit), id);

No matter how you look at it, the non-generic methods (as they are today) are going away.

ajj3085 replied on Thursday, October 29, 2009

The plan makes sense. I bring up Obsolete though because since you've started handling Csla more like a framework as opposed to example code, it might make sense to have a more formal way to retire portions of the API.

Slapping Obsolete on classes, methods, etc. once the decision has been made to abandon them I think would be a good idea. The attribute can be applied as a warning shot that "this code is likely going away soon." Maybe standardize the number of releases before the API is actually removed / no longer will work. As developers upgrade, the compiler will tell them what sections of code they need to pay attention to, and give them a chance to change before the API simply breaks.

This might be a fair trade-off between keeping backward compatibilty while allowing the framework to continue to evolve as well. Maybe not as fast as some would like, but I think there are plenty that would rather it be slower too... so maybe this can be a compromise.

Just an idea, anyway.

RockfordLhotka replied on Thursday, October 29, 2009

True, I could put the attributes in 3.8.1 or something.

rxelizondo replied on Thursday, October 29, 2009

I have nothing against obsolete attributes but if all possible, please surround the code that will become obsolete with a conditional compilation symbol. This way, people can setup the project to not include such code when the CSLA is compiled.

I say this because I am the kind of guy that is more into getting a compiler error than getting a compiler warning. Warnings can be easily overlooked, compiler errors are in your face messages. I have no need for backwards compatibility, if I use a new version of the framework then I adapt to the new code so warning are useless to me.

This could also help you to make 100% sure that obsolete functionality is not part of new functionality as you refractor the CSLA.

ajj3085 replied on Friday, October 30, 2009

rxelizondo:
I have nothing against obsolete attributes but if all possible, please surround the code that will become obsolete with a conditional compilation symbol. This way, people can setup the project to not include such code when the CSLA is compiled. I say this because I am the kind of guy that is more into getting a compiler error than getting a compiler warning. Warnings can be easily overlooked, compiler errors are in your face messages. I have no need for backwards compatibility, if I use a new version of the framework then I adapt to the new code so warning are useless to me. This could also help you to make 100% sure that obsolete functionality is not part of new functionality as you refractor the CSLA.

Please realize that you're NOT the only one actually using this framework.

rxelizondo replied on Friday, October 30, 2009

ajj3085:
Please realize that you're NOT the only one actually using this framework.

Hi ajj3085

I knew that sooner or later I would get in someone’s nerves with my “all in or all out” philosophies :)

Of course I realize that I am not the only one that uses the CSLA, but I don’t see how adding a conditional compilation symbol in this case would cause any issues whatsoever with backwards compatibility. I only see benefits here.

Am I missing something?

RockfordLhotka replied on Saturday, October 31, 2009

In the end Obsolete doesn't really play here, because the changes I'm talking about making require that the methods just plain go away - or at best change their signatures. Either way, marking them obsolete isn't meaningful in this particular context.

Henrik replied on Thursday, October 29, 2009

I also vote for "killing" the non-generic DataPortal in 4.0.

Regent replied on Thursday, October 29, 2009

I use the generic methods only too.

rasupit replied on Thursday, October 29, 2009

Never use the non-generic ever since the existence of generic. I'm voting for removing the non-generic version too.

Russ replied on Thursday, October 29, 2009

I currently support many CSLA based projects. I think I have kept all the evolving ones up to date. One way to be sure is to remove the non-generic methods. If it breaks I'll fix it or I'll simply leave the project referencing the older CSLA version.

I much prefer simplicity and I encourage you to accelerate the removal of backward compatible interfaces for the following reasons:

1) If you have created a better way to do something I may not always catch the blog and continue following the old pattern only to have to change all that code later.

2) You will have less code to support and your next book will be a little thinner.

3) Having fewer ways to do the same thing within the framework reduces the learning curve for new programmers. A lot of time is spent researching and comparing the available options.

Just my opinion.

Keep up the great work.

TAC replied on Thursday, October 29, 2009

I'd be happy for that change.

While your at it maybe consider removing the non-generic LoadProperty, or at least renaming it.
My problem with it is let's say we have a string property called 'Name'
to load it I would say...
LoadProperty(NameProperty, dr.GetString("Name"));
That's fine, but you don't actually get the strong type checking you'd expect, if you said...
LoadProperty(NameProperty, 5);
it would fall back on the non-generic method.

This is why I always say
LoadProperty<string>(NameProperty, dr.GetString("Name"));
but it would nice to not have to do that.