CodeSmith Community
Your Code. Your Way. Faster!

problem with a non-abstract ProviderBase class

rated by 0 users
This post has 26 Replies | 5 Followers

Top 500 Contributor
Posts 19
Points 310

I like using the virtual method, too!  (I hadn't thought of that.)  It just depends if you want to force implementation in the derived classes or not.  Since there are no apparent drawbacks, does this mean the templates will be updated to make the concrete base classes abstract by default, as suggested above?  It looks like this would help give the best of both worlds.  This way, if I choose to use an abstract method in my DAL to force implementation, then I won't have to create another (empty) partial class just to make the SqlClient abstract.  And it still allows me the option to use a virtual method in the DAL and not force implementation.  Cool

Stan

  • | Post Points: 15
Not Ranked
Posts 6
Points 300

True..using the 'virtual' way is absolutely easier to work with. However, it moves the focus to runtime testing instead of compile time testing. Perhaps this is a matter of taste, but I would always choose the compile time guarantee over a runtime exception. That is one of the things I like about C#...

I understand you point about class generation and I even agree with it. Flexibility should prevail over simplicity. As Albert Einstein used to say: Make everything as simple as possible, but not simpler. and who am I to disagree with him ;)

One final question: will you change the templates to make the class of my original post abstract? And if so, when would this be released?

 

  • | Post Points: 35
Top 10 Contributor
Posts 767
Points 23,160

Hi Chrisis,

The base classes have been marked abstract as of SVN 475.

Ben Johnson
------------------------------
 Member of the .NetTiers team
 Visit http://www.nettiers.com
------------------------------

  • | Post Points: 35
Not Ranked
Posts 8
Points 155

Hi,
your changes are in SqlClient project only not in WebServiceClient and it's impossible to build generated solution. The error is in WsNetTiersProvider class - can't create instance of abstract class "this.innerCustomerProvider = new CustomerProvider(this.url)".

There is a patch in attachment(only classname is changed not name of generated base class file).

Jan Melichar

 

  • | Post Points: 60
Top 10 Contributor
Posts 767
Points 23,160

Hi Jan,

Something doesn't look right in this.  You might want to double-check your copy of WsEntityProvider.generated.cst.  It looks totally different than my copy of SVN 475.  I am able to successfully build the web services project against the Northwind database.  I have attached a copy of the file from my system.  Can you compare this with your working copy?

Ben Johnson
------------------------------
 Member of the .NetTiers team
 Visit http://www.nettiers.com
------------------------------

  • | Post Points: 35
Not Ranked
Posts 8
Points 155

I can't download the attachment:( Is it possible make zip archiv?

I am using this address for svn - https://svn.sourceforge.net/svnroot/nettiers/source/trunk/Source
is this ok?

  • | Post Points: 5
Top 10 Contributor
Posts 767
Points 23,160

Sorry, I had a bit of a brain fart there.  Your patch looks fine as far as I can tell.  I should note that this is a breaking change, due to the necessary changes in the concrete provider classes (those without .generated in the name).  If you don't have custom code, you can just delete these files and regenerate.  If you do have custom code, you can manually make the following changes shown in red:

public partial class Ws[Entity]Provider: Ws[Entity]ProviderBase

      {          

            /// <summary>

            /// Creates a new <see cref="Ws[Entity]Provider"/> instance.

            /// Uses connection string to connect to datasource.

            /// </summary>

            /// <param name="url">The url to the nettiers webservice.</param>

            public Ws[Entity]Provider(string url): base(url){}

      }

}

Thanks for the contribution.  Committed as SVN 477.

Ben Johnson
------------------------------
 Member of the .NetTiers team
 Visit http://www.nettiers.com
------------------------------

  • | Post Points: 35
Not Ranked
Posts 8
Points 155
I know, I included this in that patch, but I have one question, will
you change the name of the template "WsEntityProvider.generated.cst"
and names of generated files (WsXXXXProvider.generated.cs vs.
WsXXXXProviderBase.generated.cs) like in BLL, DAL ans SqlClient?

2007/2/7, bgjohnso :
>
>
> Sorry, I had a bit of a brain fart there. Your patch looks fine as far as I
> can tell. I should note that this is a breaking change, due to the
> necessary changes in the concrete provider classes (those without .generated
> in the name). If you don't have custom code, you can just delete these
> files and regenerate. If you do have custom code, you can manually make the
> following changes shown in red:
>
> public partial class Ws[Entity]Provider: Ws[Entity]ProviderBase
>
> {
>
> ///
>
> /// Creates a new instance.
>
> /// Uses connection string to connect to datasource.
>
> ///
>
> /// The url to the nettiers
> webservice.
>
> public Ws[Entity]Provider(string url): base(url){}
>
> }
>
> }
>
> Thanks for the contribution. Committed as SVN 477.
>
>
>
  • | Post Points: 35
Top 10 Contributor
Posts 767
Points 23,160

XjsDog,

 The file names have been changed in SVN 480.  I should note that this change will leave extra files in your WebServiceClient directory if you are regenerating a project that was generated prior to SVN 480.  You will have a Ws[Entity]Provider.generated.cs and a Ws[Entity]ProviderBase.generated.cs.  The first file is extraneous and can be deleted (it is also not included in the project).

Ben Johnson
------------------------------
 Member of the .NetTiers team
 Visit http://www.nettiers.com
------------------------------

  • | Post Points: 35
Top 150 Contributor
Posts 45
Points 905

Some people in this thread mentioned the virtual method approach with throwing an exception as the default behavior to work around the lack of the SqlEntityProviderBase being abstract.

I don't like this style. I would prefer the method to be abstract. It forces anyone implementing a new provider to be aware of the existence of the method. It's then their prerogative to throw an exception if they don't want to implement the method, but I don't think that should be a default behavior that can be accidentally overlooked by the provider author.

I concede that it's only a tiny difference, but I do prefer it.

So what happened to making the SqlEntityProviderBase class abstract? Ben, you said you made the change, but as of version 2.0.1.147 the class is non-abstract.
 

  • | Post Points: 5
Top 10 Contributor
Posts 767
Points 23,160

The change was made in version 475.  I just double-checked the latest code (SqlEntityProviderBase.generated.cst) and it’s abstract.  Version 471 will not be abstract.

 

Ben Johnson
------------------------------
 Member of the .NetTiers team
 Visit http://www.nettiers.com
------------------------------

  • | Post Points: 35
Top 150 Contributor
Posts 45
Points 905
Oh, I see. *smacks forehead*. I didn't realize that the SVN 475 number you mentioned was the same as the number in the release version. So of course 471 is not going to have your 475 change. Embarrassed
  • | Post Points: 5
Page 2 of 2 (27 items) < Previous 1 2 | RSS
Copyright © 2010 CodeSmith Tools, LLC