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

  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

    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.


    Can you see what I am suggesting?

    Thanks for the feedback.


    "ian drake" <ian.drake1@home.com> wrote in message
    > I checked out your site. I was a little confused about your initial

    > 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

    > 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

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

    > 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

    > 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,

    > 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

    > 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

    > 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

    > 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

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

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

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

    > 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

    > 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

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

    > 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

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

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

    > >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
Latest Articles
Questions? Contact us.
Web Development
Latest Tips
Open Source

   Development Centers

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