Re: N-Tier Design Question?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: Kevin Spencer (kspencer_at_takempis.com)
Date: 09/27/04 

Date: Mon, 27 Sep 2004 17:21:52 -0400

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" <vnality@msn.com> wrote in message
news:OprBYYNpEHA.648@tk2msftngp13.phx.gbl...
> 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" <kspencer@takempis.com> wrote in message
> news:u4ykI9MpEHA.3876@TK2MSFTNGP15.phx.gbl...
> > 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" <vnality@msn.com> wrote in message
> > news:#gwGefMpEHA.2484@TK2MSFTNGP09.phx.gbl...
> >> 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
> >>
> >>
> >>
> >
> >
>
>

Relevant Pages

  • Re: N-Tier Design Question?
    ... I understand exactly what you are saying, but when I spoke of Business ... > organizes and maintains all functionality for a single user of your app. ... > custom Server Controls for various functionality. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: basic asp.net 2.0 question
    ... The drag and drop functionality will fit most read only implementations ... if the app grows). ... If you head to a fairly standard business and data tier, ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: n-tier performance trade-off (guidance needed)
    ... We split apps up in tiers as we often ... network bandwidth or because we want to re-use functionality without rework, ... Where you start seeing benefits in a desktop app is often related to using ... single interface app for a single puropose when business functionality is ...
    (microsoft.public.dotnet.general)
  • Re: Loading VB files?
    ... How 'bout finding something that'll get VB6 source from an app it ... does it take to start the first dotNet app of the day?... ... functionality", mmmkay? ... tells me these "knowledge or skills" are about 15 years behind... ...
    (microsoft.public.vb.general.discussion)
  • Re: [kde] Why KDE4 is called KDE?
    ... That is an insane amount of work to add a console app. ... I've found it quite easy to customize, ... parallel functionality -- with at least close to parallel lack of ... based not on colors or functionless eye candy like the plasmoid. ...
    (KDE)