N-Tier Design Question?

[Leon]

Is it a good idea to use visual studios .net code default solution and
compile business object (business rules and logic) together? or is code
behind sufficient enough? I know about modules, but I think they are a
little too much for the application am developing.

background Information:
I'm working on a web application with multiple programmers/graphic designers
but we are locally accessible. I want the application to be easy to
maintenance as well as extend. Plus I think if I use a .vb that contain all
of "let say" user interaction information ("such as registration, login, and
update and delete profile") and reference ("Import Namespace") that file
from within my code behind file verse using a totally separate code behind
..vb file for all of my .aspx files.

Conclusion:
..aspx file + CodeBehind File + BizLogic File = Success
OR
..aspx File + CodeBehind File = Success

"What's Your Opinion?"

Thanks

 

[Kevin Spencer]

Hi Leon,

"N-Tier" is a nice buzz word that seems to get passed around a lot these
days. I would advise you not to think about tiers, but about principles
instead. If you can do so successfully, the tiers will take care of
themselves.

What are the principles? Well, you stated some of them yourself:

I want the application to be easy to
maintenance as well as extend.

That is the chief purpose of all these high-sounding terms that get tossed
around these days, like "MVC" and "N-Tiered." What is it that makes an app
easy to maintain, and easy to extend? Well, organization is the key, and
separation of the various types of functionality is the idea. For example,
you can certainly visualize the difference between a User Interface object,
such as a Web Control, and a Business Logic object, such as a class that
organizes and maintains all functionality for a single user of your app. One
renders HTML in the browser, so that the user can read and interact with it.
Another contains data and functionality for manipulating a set of data.

The key is to keep these "loosely coupled." That is, don't mix them
together. An application, whether it is an executable or a web app, is never
finished, at least until nobody is using it any more. Typically, apps are
launched, and then revised, and re-launched, and revised, etc. etc. etc.
There are several logical divisions of functionality, one of which I have
already mentioned: User Interface vs. Business Logic. A good web app
separates UI from Business logic, so that it is easy to make changes to one
or the other without having to think about the other. The UI is bound to the
business class by some programming interface, which you generally don't want
to change. However, beyond that, you may want to change the way the data
looks when displayed, or you may change the underlying structure of the
data, or enhance functionality without breaking the User Interface.

If you first organize the various logical elements of your app, and keep
them loosely coupled, maintanance and extensibility should be a snap. Of
course, the planning and organization are the most critical parts of the
process. They are the foundation upon which you build. There are many ways
to separate out the various elements. For example, in our web app, we use
custom Server Controls for various functionality. These Server Controls are
built in such a way that they can operate independently of each other. That
way, we can combine, move, and/or revise any of them without affecting the
rest of the app. The Server Controls are all UI, no business Logic. For
that, our Server Controls use Business classes, which handle and manipulate
the data. In addition, we use CSS for layout and positioning. This means
that our developers don't have to think about what the UI will look like to
the user. Our graphic designers create the CSS that handles this.

One final word of advice: Bone up on OOP (Object-Oriented Programming).
Forget about "CodeBehind." A CodeBehind class is just that: a class. It is
much like any other class. It is best to think about classes, not files.
Files exist on the file system. Classes exist in an application. Once the
app is compiled, the files are irrelevant. And thinking in terms of files
only confuses the issue.

Don't use Modules. They are there for backwards compatibility, a kind of
crutch for VB developers who are migrating to OOP and .Net. A Module is
actually compiled to a class, but a static class. However, you can create
any static methods, properties, etc., that you need without ever touching a
Module.And static elements are not as useful as you would think in the .Net
environment. Get used to thinking OOP. It is uncomfortable at first, but
becomes intuitive in a relatively short period of time.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Leon]

Thanks Kevin,

I understand exactly what you are saying, but when I spoke of Business
Objects/Logic I meant the .vb code page which include Public Classes.
Example:
.....
.....
Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace

Are You Talking about the same thing? "I trying to make sure I fully
understand you"

Background Information:
I acceptable understanding OOP, but no way a professional.

 

[Kevin Spencer]

Hi Leon,

Again, forget about files and pages. Think in terms of objects. A single
file can contain multiple class definitions. And the file is only used at
compile-time to build the classes. In other words, try to think of these
things as abstract entities, not files. The code to create them is in files,
but the entities themselves are not.

For example,let's take a look at your example:

Namespace Leon
Public Class User
Public Function Login(...)
....
End Function
Etc.
Etc
End Class
End .Namespace

This is a class definition. It is NOT a class. A class is an instance of the
definition. You can have many User objects, each with its own set of data,
different from the rest, but sharing the same class definition. So, how can
every User object be a file? There is only one file. And it is not used at
run-time; an in-memory object is.

A class is a type, just like Integer or String. If it helps you to think of
it this way, note that you can have many Integers or Strings in an
application. The only thing they share in common is their data type. And
remember that "Integer" (the type) is not a number. It is the definition of
what an Integer is. It's the same thing with a class. A class definition
simply defines the type of data that a class is. A class (the type) is not
an instance of a class any more than Integer is a number, or String is a
string.

I hope this doesn't sound nit-picky, but it is extremely important to think
of these things in this way to be successful with OOP.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
I get paid good money to
solve puzzles for a living

 

[Leon]

I think I know exactly what you are talking about, but I will now start to
tighten-up on my OOP skills.
thanks Kevin!

 

[Leo Muller]

I have had the same considerations, and recently reconsidered and revised
the way we worked.
The evolution is like this:
1- used only code behind. Major disadvantage, no code reuse.
2 - wrote another project with the shared functions, worked good, but a bit
of trouble with the references used to other projects, while being used by
different programmers.
3- used a certain class in the project to give the shared functionality,
solved previous problem, but still not perfect. Mainly because this class
would be copied over to different projects.
4 - The best solution so far: - wrote my own namespace (solution with
projects) with all shared functions. Within this I compiled the Microsoft
Data Application Block as well. Copy the DLL over to a directory accessible
by all programmers. Let them set reference to this DLL. (not to the
project!). and use the class as mycomp.data.sqlhelper, or
mycomp.text.countwords(). Can be developed seperately, and released whenever
they are ready.
If anyone want the sourcecode of this project, just let me know. The way it
works is soooo simple and straighforward, I just want to develop in order to
use it! Call me a freak.

Now the great point of .Net is that changing between these different ways of
working is surprisingly easy.

Leo Muller

 

[Leon]

I understand exactly what you are saying, but I think it's good idea to use
both CodeBehind as well as the compile dll using the vbc.exe Compile this
allows
you to further separate code from presentation right. What's your opinion?