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.
Stan
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?
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------------------------------
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
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?
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/Sourceis this ok?
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.
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).
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.
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.