"Code Behind" = Less Spaghetti Code, MORE SCATTERED Code


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 2 of 2

Thread: "Code Behind" = Less Spaghetti Code, MORE SCATTERED Code

Hybrid View

  1. #1
    com no spam lift Guest

    "Code Behind" = Less Spaghetti Code, MORE SCATTERED Code

    Web site discussing the "increased" DNA Architecture Design Complexity with
    Visual Studio.NET

    DNA Layers and "Code Behind" Towers
    http://www.geocities.com/comdna/


    Any comments appreciated. (Oh, just flame away if you want to.)



  2. #2
    com no spam lift Guest

    Re: "Code Behind" = Less Spaghetti Code, MORE SCATTERED Code

    Yes, I can your point about having 2 .aspx pages accessing the same business
    logic. And then having to write the logic in 2 places.

    I address that by having the options with that Right Click Menu to make
    "clones of that business logic on both of those aspx pages. Also, I have an
    option to update all the clones of that same business logic across all pages
    of the web site.

    http://www.geocities.com/comdna/dna_page_3.html

    Can you see what I am suggesting?

    Thanks for the feedback.

    c







    "ian drake" <ian.drake1@home.com> wrote in message
    news:3a2e7003$1@news.devx.com...
    >
    > I checked out your site. I was a little confused about your initial

    analysis
    > of the DNA model and would like to point out some potential pit falls in
    > your model. Of course VB programmers have many new tools available to us.
    > I, for one, am adjusting the model I'll be using for internet development
    > and I'll share that with you too.
    >
    > One thing, from my understanding, aspx classes inherit from the code

    behind
    > class and, in .NET, multiple inheritance is not allowed. With that said,
    > if you put your Business logic in you code behind page, is it still

    modular?
    > If I have the Bussiness logic to add a User in the code behind of

    user.aspx
    > and I want to add a User from addmember.aspx as well, do I want to have to
    > recreate the code and maintain my business logic in two places?
    >
    > Also, you spoke about the BLL being in one file which makes it difficult
    > for several developers to edit at the same time. I'm not sure that is

    acurate,
    > unless you, by your own choosing, put all your business layer classes in
    > one file. You don't have to do this. You can have one class per file,

    and
    > still have all classes in the same namespace.
    >
    > You also spoke of single point of failure. Maybe I missed your point, but
    > whenever you have n-tier model you are faced with the fact that if one of
    > the tiers stops working than the whole app stops working. But the point
    > of the n-tier model is that it is up to you to scale, and make highly

    available,
    > each tier. If, as you pointed out, the BLL stops working, then the whole
    > site will stop working. I don't think that is a fair argument for

    including
    > the BLL in the code behind classes. It would be like saying, "what if the
    > web server failed?", would you get rid of the presentation layer? Of

    course
    > not, you'd make sure you had a fail over.
    >
    > Sorry about the critism, I'm just letting you know how I see it.
    >
    > The following is the way I am approching the n-tier model with .NET: (I

    make
    > no claim that it is right or better, but like you I'm intersted in

    feedback
    > and potential problems.)
    > I create the folowing logical layers:
    >
    > Presentation - Primarily .aspx pages containing HTML and ASP.NET server

    controls.
    > All pages will inherit from their corresponding class in the Workflow

    tier.
    >
    > Workflow - VB.Net (code behind)classes that control work done by and for
    > any page in the presentation tier. Workflow tier will use Business and

    Dataworker
    > tiers to complete their tasks.
    >
    > Business - VB.NET classes that perform/enforce business level rules. The
    > Business tier will consume classes from the Dataworker and Data tier.
    >
    > Dataworker - VB.NET classes that abstract individual tables in the

    database.
    > From these classes are where most data will be accessed. All Dataworker
    > classes will inherit from ADO Datatables. It is expected that all

    Dataworker
    > objects can be cast into XML for state management between page calls.
    >
    > Data - SQL Server 2000 Database with stored procedures. Will be accessed
    > primarily by the Dataworker classes
    >
    > I also use some objects that provide service to my other layers.
    >
    > DBAccess - Simplifies data access to SQL Server 2000 through ADO.NET
    >
    > LogManager - Simplifies logging for applications. Abstraction of logging
    > is needed to determine where and when to log.
    >
    > StateManager - Simplifies state logic and maintenance. Service will

    control
    > session state only. There are two types of session state, Object State

    and
    > Variable State.
    >
    >
    > "com no spam lift" <com_no_spam_me_lift_jose8@pacbell.net> wrote:
    > >Web site discussing the "increased" DNA Architecture Design Complexity

    with
    > >Visual Studio.NET
    > >
    > >DNA Layers and "Code Behind" Towers
    > >http://www.geocities.com/comdna/
    > >
    > >
    > >Any comments appreciated. (Oh, just flame away if you want to.)
    > >
    > >

    >




Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center