Business Layer

  • Thread starter Thread starter Green Taylor
  • Start date Start date
G

Green Taylor

Hi Gurus,

I am still a new developer, learning things everyday, need some concept
advices (Windows App.). I have learned that we should keep our code seperate
from user interface layer.

Suppose I have a form named Form1.

Before framework 2.0 we were creating a new class(Business layer) and put
all the code on it to keep it seperate from user Interface code.
But in Framework 2.0 Microsoft is automatically seperating the user
interface code and put it in a Form1.Designer.vb.

My question is if I don't create a new bussiness layer class and just use
the default class(Form1.vb), then is it against the rule of business layer,
or should I continue to use the Business class.

I need some advises/suggestion.

Thanks for any help you can provide on this.
Green
 
Green,

What you describe are called "partial classes". The main purpose and use of
partial classes is to allow for code generation to work better with non-code
generated content. The IDE generates the code for your controls on the form
but it does not alter the procedural code that you add to interact with your
controls. This should really be the limit to which partial classes are used.
Others might offer differing opinions.

I think that business or data logic should remain in different classes.

The place where your suggestion breaks down is if you want to create an
application that is both web based and forms bases. Putting business logic /
code in the partial class for the form does not allow it to be shared
between the two. In addition, your business code will typically contain
logic that can be shared between multiple forms.

Hope this helps.
 
Green,

Andrew is absolutely correct. I wanted to jump in with some general
advice. It's great that you are learning and that you are asking these
questions to a community of peers. I would urge you to consider this.
The fact that you have a single class called BizLayer, is not enough
abstraction. You should really be looking at what metaphors exist in
your problem space and creating classes that represent and manage those
metaphors. We could talk for a long time about how to do interface
abstraction, decoupling, and proper design, however there are many more
qualified then me and may books discussing it. I am glad you are
asking questions and encourage you today to start to read about design
principals and patterns. You may not get them yet, but they will start
to make sense as you continue to build software. There is one in
particular that helped me with my designs. The "Single Responsibility
Principal". Start with that one. It will help you understand that
your system is made up of many classes (i.e. metaphors) and you should
not be afraid of brining them to life.

Just hoping to spur design thought in a new developer. Remember
computer science is not about the technology, it's about problem
solving. Solving problems is about understanding them. Understanding
them is about breaking them down. Break them down by using metaphors.

Hope this helps,
Michael Moser
 
I have one more question.
Is is always a good idea to create a bussiness logic in a new class even if
we don't use/share it anywhere else.

Green
 
A better way to think about what you are asking is maybe should you be
putting more than one class in each file? Some argue that putting multiple
related classes in one physical file is a good thing. I put each class in
its own file with very very few exceptions. Sometimes building business code
into a class helps simplify design and improve readability even when said
business code is used only in a single place. And you never know when you
might reuse the same logic else where in your application.

Like all aspects of programming, there are many ways to look at this and
typically, there is never only one correct answer. I often wonder if I am
writing and designing in the "best" way. It is nice just knowing that others
struggle with these issues just as I do.
 
It's been my experience that every class as Andrew says should be in
it's own file. It's just easier for the next guy or gal who works with
your software to find their way around your solution.
 
Back
Top