Hi all, I have created manager classes for all my entities which seems to be working well. The issue I'm wondering about is should I make all functions in the manager classes static? What are the benefits to doing this? Right now there not and I'm constantly having to create new instances of a manager class to get access to its functions. What's the best practice for this? Any advice would be appreciated.

First of all you may want to check out the Manager templates over in the Template Studio forum before reinventing the wheel. http://llblgen.com/tinyforum/Messages.aspx?ThreadID=1947

The reason for static methods is that there is no instance information in the classes at all. The managers only provide methods for doing work on entities.

*Manager.Fetch(id), *Manager.Save( entity ) .... and so on...

But what if you decide that there is common functionality that you want all methods to have (for example initialising a dataadaptor class), and so decide to make the dataaccessadaptor a field of the class and initialise it in the class constructor?

MattWoberts wrote:

But what if you decide that there is common functionality that you want all methods to have (for example initialising a dataadaptor class), and so decide to make the dataaccessadaptor a field of the class and initialise it in the class constructor?

Marking a method as "shared/static" gives you simplicity and ease-of-access at the cost of maintaining state - in fact that's exactly how it simplifies it. If you have common methods or data that needs to be "shared" across methods, I use "Private Shared". This "simulates" instance methods, at the expense of longer argument lists.

Jeff...

MattWoberts wrote:

But what if you decide that there is common functionality that you want all methods to have (for example initialising a dataadaptor class), and so decide to make the dataaccessadaptor a field of the class and initialise it in the class constructor?

If you really wanted one DataAccessAdapter for your manager class, you could define as a static member

private static DataAccessAdapter adapter = new DataAccessAdapter();

But, you don't have to go through the trouble of doing that if you use the manager templates that I refered you to. All methods have overloads for using a DataAccessAdapter.

FetchCollecion()
{
    using( DataAccessAdapter apdapter = new DataAccessAdapter() )
    {
        return FetchCollection( apdapter );
    }
}

FetchCollecion( DataAccessAdapter adapter ){...}

Hope that helps a little

A factory class can provide you with the instance in a single line of code. Thats their purpose in life. Frans uses them all over the place in llblgen.

I have reworked the manager templates to be instance specific, I just havent done a whole lot with them yet to give my changes a test run. I did this so that instances of my manager classes can be passed to an instance of a class that is managing COM+ Context and my manager class will enlist in the COM+ context.

Also, in last month's issue of MSDN magazine there was a good write up of how and when to use statics and how to make "proper" use of statics.

Devildog74 wrote:

A factory class can provide you with the instance in a single line of code. Thats their purpose in life. Frans uses them all over the place in llblgen.

I have reworked the manager templates to be instance specific, I just havent done a whole lot with them yet to give my changes a test run. I did this so that instances of my manager classes can be passed to an instance of a class that is managing COM+ Context and my manager class will enlist in the COM+ context.

Also, in last month's issue of MSDN magazine there was a good write up of how and when to use statics and how to make "proper" use of statics.

I'd love to see your changes. Please branch your code into the repository.

Is there anything in that article about "proper" use of statics that hasn't been covered in this thread? IMO MSDN mag is mostly a bunch of beginner stuff. Not that being a beginner is bad though. We all have to start somewhere.

cmartinbot wrote:

I'd love to see your changes. Please branch your code into the repository.

I will try to get this done so you can check it out next week.

cmartinbot wrote:

Is there anything in that article about "proper" use of statics that hasn't been covered in this thread?

Yes actually, they talk about how statics get compiled into msil and how explicit vs implicit initialization can have an impact on performance. And they also talk a bit about how static classes that maintain state should be made to be thread safe.

All in all, thats is what isnt covered in this thread. Its pretty short: http://msdn.microsoft.com/msdnmag/issues/05/01/StaticsinNET/

cmartinbot wrote:

If you really wanted one DataAccessAdapter for your manager class, you could define as a static member

private static DataAccessAdapter adapter = new DataAccessAdapter();

Be very careful here as DataAccessAdapter may not be thread safe. Whenever I see static I think of threading problems.

If you application is single threaded then this will not be a problem. If you are using ASP.NET or WSE 2.0, then this is a multithreaded environment. Watch out.

cmartinbot, devildog

thanks for the input. I haven't had a chance to install the template studio yet buy will try to get to it this week. In your manager templates, do they return llblgen entities or datatables? Currently in my manager classes I have been returning datatables.

erichar11 wrote:

cmartinbot, devildog

thanks for the input. I haven't had a chance to install the template studio yet buy will try to get to it this week. In your manager templates, do they return llblgen entities or datatables? Currently in my manager classes I have been returning datatables.

They return Entities and EntityCollections. But, there is a superclass genereated for you to add custom code to.

Marcus wrote:

cmartinbot wrote:

If you really wanted one DataAccessAdapter for your manager class, you could define as a static member

private static DataAccessAdapter adapter = new DataAccessAdapter();

Be very careful here as DataAccessAdapter may not be thread safe. Whenever I see static I think of threading problems.

If you application is single threaded then this will not be a problem. If you are using ASP.NET or WSE 2.0, then this is a multithreaded environment. Watch out.

Good point. That's why the manager templates do not include that.

newbie here so forgive me if this is a simple, but what's the issue with threading and static as Marcus mentioned?

erichar11 wrote:

newbie here so forgive me if this is a simple, but what's the issue with threading and static as Marcus mentioned?

A static member belongs to a Type not an instance of a Type. So, if when working with a static member and another thread comes in and changes it in some way (changing properties and such), those changes are reflected to ALL threads using the Type.

This isn't the best example in the world but it should get the point across.

public sealed class MyEntityManager
{
    public static DataAccessAdapter adapter = new DataAccessAdapter();
    
    public static MyEntity Fetch( int id )
    {
        return base.Fetch( new MyEntity(), adapter );
    }
}

public class Test
{
    MyEntity entity = MyEntityManager.Fetch( 2 );
    
    //On another thread. I'm not writing the threading code
    DataAccessAdapter adapter = MyEntityManager.adapter;
    adapter.ConnectionString = "someother connetion string";
    
    entity = MyEntityManager.Fetch( 2 );
}

The problem here is that entity will be completely different on both threads. Not only that but, the connection string will remain the same for all threads.

It's potentially "dangerous" to use static memebers in classes.