I recently started working on a project that tries to use this business layer, however it seems that the senior engineer that implemented it did not understand what he was doing, I am hoping somebody can verify that we are using it incorrectly so I don't go crazy, it appears that we are losing a lot of development time because if it, and the amount of code reuse is minimal, the maintainability is also poor, stale data is a problem, etc.

In summary, our application consists of many forms or screens that the user can use. For each form we have business entity. This is how we use the business entity.

All the business logic for a screen goes in this business entity, all business logic for the respective screen is kept in this file, the only way to access this logic is to call CheckBusinessRule

The only public method we use is CheckBusinessRule

We also have a separate file where all the business rule args are stored for the entire solution.

Example of using business layer;

1)      create a new Argument class for each method in the business layer, this method will use this class for it's parameters

a.       Class MyMethodArgs .. etc, public members of this class represent the parameters for the method that will be called.

b.      All these classes are kept in a separate file, so any method that has business logic, you must create a new class to hold the parameters, as you can imagine this is time consuming, and there are many of these classes

2)      Set up the eventhandlers, delegates, actual method, etc in the business entity

3)      In the presentation layer, instantiate the singleton business object, instantiate the rule args, call MySingletonBusinessEntity.CheckBusinessRule(MyRuleArgs), take the updated values out of MyRuleArgs and use as needed in the presentation layer.

UserArguments args = null;

args = new Business.RuleArguments.UserArguments(BusinessRuleNames.SetUser);

args.UserName = name;

if (!userBusiness.CheckBusinessRule(BusinessRuleNames.SetUser, args))

   {

   // handle exception              

   this.Close();

   return;

   }

The only method our business object ever calls is CheckBusinessRule, some screens may have 20+ checkbusinessRule calls to different methods, the overhead is enormous.

We do not have any other classes that describe how our system works, such as a user class; we use datarows or datatables for everything, thus there is no or very minimal encapsulation, really no inheritance either, or any other object oriented attribute.

Does this seem even reasonable? Intellisense, strongly typed data members, operator overloading, debugging, inheritance,etc we lose all this because of this manner to call methods in the business entity. Is this the intended use of the business layer? Just seems like an awful lot of work to call a method.