Static Method Abstraction

rodmcleay · March 26th, 2009, 11:18 PM

Hi All,
I wish to impliment a n-tier architecture that allows me to replace the BLL class.
I am having trouble working out hte correct syntax of abstracting out the static methods of the class.

If I have an instance of a class I can call the static methods of that class, but who do I make it so that I can use an interface of some other representation of the contrete class and still refer to the static methods directly.

Eg.
Onload()
{
datasource = Person.GetAllPeople();
}
But I want the particular dll providing the Person class to be defined in the presentation layer.
In a non static environment I would do soemthing like this.
Type type = Type.GetType("myassembly, Person");
IPerson lp = (IPerson)Activator.CreateInstance(type);

But realy what I want to do is call a static method of the type itself without instantiating a class.
IE, IPerson.GetAllPeople();

What approach should I take to this, interfaces don't seem to fit the bill.

Any assistance would be greatly appreciated.

Rod

gbianchi · March 26th, 2009, 11:30 PM

I'm not an expert explaining this. But a static method can be call without instantiating a class.
If you have a class named foo, and a method named a, you can in your code just do
foo.a without having a specific class variable from it. Are you asking about this?

rodmcleay · March 27th, 2009, 12:29 AM

Hi Gonzalo,
Thanks for your response, but I am looking for the way to refer to the class dynamically at run time as you might with an interface.

So I wish to call the method foo.a, but not knowing what assembly foo belongs to at design time.

Im having a hard time getting a grip on my question myself, sorry for the ambiguity.

Rod

Lee Dumond · March 27th, 2009, 02:01 AM

I think you may need to rethink your assumptions (and maybe brush up on your OOP a little bit?)

You wrote:

Quote:

If I have an instance of a class I can call the static methods of that class

This is incorrect.
You CANNOT call the static members of a class from an instance of the class.

Quote:

what I want to do is call a static method of the type itself without instantiating a class

That is in fact exactly how static members work. You can ONLY call static members through the class itself, without instantiation.

If you have a public class called Person with a public static method called GetAllPeople(), you can just call it directly through the class from wherever you want. Just import the namespace or assembly.

Guess that means you can put away the interfaces and the reflection methods.

rodmcleay · March 27th, 2009, 02:27 AM

Hi Lee,

Thanks for your response.
Yes, I have gotten quite muddled with my explanation, my appologies.
I'm trying to explain what I want to do with a static method, and have been using what I would do in an instantiated class as an example, this has confused me and my question.
Forget all me references to instantiation.

The bottom line is I dont want to refer to the assembly that holds the class directly, I want to abstract the business logic layer which has static methods in it.

So I want to call a static method of a class but I wish to determin the assembly/class that holds that method at runtime.

Imar · March 27th, 2009, 04:20 AM

Hi Rod,

The problem with statics is that they are tied to the actual class, and not to the class hierarchy. When you have a common base class or interface, it's easy to polymorphically call a common method on a type, but you can't do that with statics. Instead, you could use reflection to call methods on your static class. First, create a Type object of your class with the static method. Then create a MethodInfo object and call its Invoke method, optionally passing parameters. The following code shows a complete demo of this:

Code:

using System;
using System.Reflection;
namespace ConsoleApplication1
{
  public class ClassWithStaticMethod
  {
    public static string HelloWorld(string input)
    {
      Console.WriteLine("Hello World in static: {0}", input);
      return input;
    }
  }

  class Program
  {
    static void Main(string[] args)
    {
      Type typeofClassWithStaticMethod = Type.GetType("ConsoleApplication1.ClassWithStaticMethod");
      // Get a reference to the static method
      MethodInfo methodInfo = typeofClassWithStaticMethod.GetMethod("HelloWorld", BindingFlags.Static | BindingFlags.Public);
      // Define parameters for the method
      object[] methodArgs = new object[1] { "Imar" };
      // Execute it and get its return type
      object returnValue = methodInfo.Invoke(null, methodArgs);
      Console.WriteLine("Hello World in caller: {0}", returnValue);
    }
  }
}

However, I am not sure if this is really what you want. What's your ultimate goal? Do you really need statics like this? Are you trying to achieve something like the .NET Providers offer? E.g. in web.config you choose the provider (like the SqlMembershipProvider) and then at runtime simply call:

Membership.GetUser();

What happens here is that the Membership class has static methods for working with users. Under the hood, it calls instance methods with the same name on *instantiated* classes that implement the base provider's methods. E.g.:

public static MembershipUser GetUser()
{
EnsureConfiguredProvider();
return _configuredProvider.GetUser();
}

EnsureConfiguredProvider would read the config file and instantiate the right type through reflection just once.

So, IMO, a provider based model would be a lot cleaner (and probably faster) to work with.
If you like this idea, let me know and I'll dig up a link to a white paper on the Microsoft site showing how to implement your own provider model.

Hope this helps,

Imar

mander77 · March 27th, 2009, 09:00 AM

***OFF TOPIC: TO MR. SPAANJAARS***
Imar,
I know this is not the place for this, but I cannot find another way to contact you. Yesterday morning I was reading your series on your website (imar.spaanjaars.com) about n-tier applications. I LOVE them btw! Anyway, while I was in the middle of reading them, it appears that the site went down? I haven't been able to access the site since (from multiple internet providers).
I didn't know if you were aware of the problem or not. I hope you see this! Your articles are absolutely fantastic! Thanks for all the hard work you do. =)

rodmcleay · March 27th, 2009, 11:42 AM

Hi Imar,
I haven't been on wrox for a while.
I'm very glad to see you are still being so generous with your time.
You deserve a medal.
Thankyou.

Both options offer me great assistance, I will research provider's myself, I think that might fit the bill, thanks for your guidance.

I am overseeing a web service implimentation using WCF.
In the model that has been suggested by the technical designer the code seems to be very seperated physically, with different layers doing things that I would normally do in one layer.
However there is no real abstraction and I feel that maintaining two dlls that can't be seperated is overhead.
Using LinQ, and the OR mapper, the business object layer become more tied with the data layer, I can't see the point in seperating the business logic from the linq business object model.

My argument is that if bus logic abstraction is the objective we need to look again at the design.
If abstraction of the business logic is not required, then we can use partial classes to provide the functionality encapsultated in the DAL dll with the linq classes. No loss of function at all.

Not n-tier, but simple clean encapsulated and seperated at the same time with partial classes

I hope I don't need to seperate the layer, but I need to have some ideas in place.

Any comments on this would be very much appreciated.

Rod

Imar · March 27th, 2009, 12:11 PM

Hi mander77,

Yes, I know my site is down. It'll be up again some day..... ;-)

Imar

Imar · March 27th, 2009, 12:16 PM

Hi Rod,

Here's the link to the provider article. Saves you some researching

http://msdn.microsoft.com/en-us/library/aa479038.aspx

It's part of the bigger ASP.NET Provider Toolkit (samples, white papers and so on):

http://msdn.microsoft.com/en-us/asp.net/aa336558.aspx

If they can't be separated, then indeed a single DLL / class library would be a good option. But even if they can't be separated, two projects would work as well. Sometimes it's easier to have multiple projects which may lead to better compilation times (only compile what has changed) and easier maintenance (multiple developers on multiple projects).

Why do they insist on this separation?

Imar