Blazor CSLA 6.0 Best Practice Advice - ReadOnlyListBase with Fetch method and same parameter signature

[jhuerta3]

Hello All,
I have a question regarding a issue which I have been struggling with. I've asked something similar to this before and I would like to verify one more time. I have a ReadOnlyList class DepartmentList with two Fetch methods that have the same parameter signature of a string (DepartmentNumber) value and injection values. The difference between both methods is what they return. One returns a list of division and the other a list of sections.

I know that that the only way to use the same method name in a class is to have different parameters signature or use a different method name like FetchDivision or FetchSection with the attributes of [Fetch] as an example. My understanding is that these also will need to have different parameter signatures since the CSLA API will search for the [Fetch] attribute and disregard the method name to differentiate both. (Not sure if this is true or the case)

I could definitely add a dummy parameter to differentiate one of the method but I rather not do that like below:
E.g Fetch( string DepartmentNumber, [Inject] DataAccess. ..
E.g Fetch( string DepartmentNumber, int dummyparam, [Inject] DataAccess. ..

One option is to create another object SectionList that will return the list of sections but then this will leave me with an almost identical class to the one I already have.

I would like to add that I have a factory class DepartmentListFactory that I used for UI calls but within the factory class I am unable to see the method with a different name other than Fetch.

So the question is how do I resolve this issue? In other API this is not an issue and it has not been an issue in CSLA in the past. I have used the criteria class before on older version of CSLA but I read that this is no longer supported. Thank you.

[rockfordlhotka]

You are correct, that the rules for method overloading of data portal operations is the same as for C# itself. So one way or another it is necessary for the two methods to have different parameter signatures.

As you note, a dummy parameter is one solution.

Another is to wrap the string parameters in some other type. You could do this by using (for example) the existing ReadOnlyBase type:

[Serializable]
public class DepartmentName : ReadOnlyBase<DepartmentName>
{
  // declare a managed string property for the department name
  // but make the setter _public_ so it can be loaded with the value
}

That's a workable solution that incurs a little overhead because it is a business type not a "primitive" type of string. But it would resolve your scenario in what might be a more readable solution than the dummy parameter.

If you want to reduce the (already pretty low) overhead, you could create DepartmentName by subclassing Csla.Core.MobileObject. This requires a little more code, because you need to manually override the get/set state virtual methods to put the value into and out of the serialization stream.

[jhuerta3]

Hello @rockfordlhotka. I will try the wrapper class technique. I will post what I did once I’m done.
Thank you for clarifying the issue.