newbie question

smithabc1212 — Fri, 28 Sep 2007 15:23:23 GMT

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.

RE: newbie question

StrataFrame Team — Fri, 28 Sep 2007 15:23:23 GMT

The BusinessLayer class is designed to check the business rules before a save. So, most of the rule checking logic is generally placed within the CheckRulesOnCurrentRow method within the business object that inherits BusinessLayer. This method is called internally when you save a business object or when you explicitly call it on the business object. So, it really only makes sense to call the checking of the rules when the form is closing, and if the rules check out OK, then let the form close.

So, as for losing the strong-typed properties, inheritance and so forth, if you place the logic within the CheckRulesOnCurrentRow() (the stub of which is created by the template used to create a new business object), you will have access to all of the strong-typed properties of that business object.

If that didn't explain it very well, then you might try rephrasing the question in case I didn't quite get what you were trying to ask :)

StrataFrame Forum » .NET Forums » General .NET Discussion » newbie question

newbie question

RE: newbie question