>>Its kind of funny how some people (not you) complain that that a framework can't possibly be flexible enough for them and then when we lay it on the line and look at some code you complain "Its too abstract!" <g>
>>
>>You got to admit its funny.<g>
>
>I never said it was too abstract. I"m just saying trying to be everything, to everyone makes it tough for performance etc.
>
>Morgan

Yeah, I know. The business object supports data access through datasets and datareaders and calling stored procs. By the time you put all those methods on the business object (which just delegate to the dao) it gets to be quite a few methods in intellisense.

I think the way .NET works is that if you instantiate two objects of the same class there is only one copy of the method code in memory so having those methods around shouldn't hurt any. I have to study up on that one.

I know he uses lazy instantiation in properties so many objects don't get created unless they are accessed.

public static mmAppSettingsManager AppSettingsMgr
{
	get 
	{ 
		// Instantiate the App Settings Manager if it's null
		if (_appSettingsMgr == null)
		{
			_appSettingsMgr = Factory.CreateAppSettingsManager();
		}
		return _appSettingsMgr; 
	}
	set { _appSettingsMgr = value; }
}

In may cases I agree with you. If a .NET programmer doesn't know about immutable strings and boxing and garbage collection and data access they can kill performance. A competent programmer has to learn about all those things but MM.NET can't hide those things anyway.

I think if you studied it a little you would see that the framework is a good thing.