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


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 12 of 12

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
    ian drake Guest

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


    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.)
    >
    >



  3. #3
    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.)
    > >
    > >

    >




  4. #4
    Rob Teixeira Guest

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


    "ian drake" <ian.drake1@home.com> wrote:
    >
    >
    > 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 really don't want more than one developer working on files at the *same*
    time. This is what source control is for anyway.
    Components should be intelligently divided amoung team members for coding.
    Trust me when I say that through experience I have found that this eliminates
    MANY bugs.

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


    This is what testing and QA is for. Oh, I'm sorry, testing and designing
    are no longer in vogue.
    But there's also another issue pertaining to code centralization. Chances
    are that if you have the same code in many places, there has been a lot of
    copy-paste. So what happens when the code needs to be fixed/upgraded? That's
    right, you've exponentially increased your work and potential for further
    bugs/inconsistancies.
    And if your BLL fails for whatever reason, it will now fail in the same manner
    over several areas of the app - which is no different from a central component
    failing.

    -Rob

  5. #5
    ian drake Guest

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


    I see now what you are suggesting. I guess it comes down to which of the
    following statements you agree with:

    1. It is the job of the IDE to logically group, track and manage business
    logic code.

    2. It is the job of the developer to logically group code into objects that
    can be reused from many different places.

    In some aspect I can see your point. Being able to see all the code that
    is getting run is a convience that you don't have in OO. You find yourself
    constantly following the path of logic. Diving into classes that you didn't
    write to find the guts of what the **** it's doing. Many times having to
    go several levels deep. Let's face it, must components developed in house
    are not black boxes, nor documented.

    But I couldn't give relinquish the responsiblity of my logical code mangement
    to the IDE. I like the OO approach, and although frustrations can arise,
    I think most people like it too.

    ian

    "com no spam lift" <com_no_spam_me_lift_jose8@pacbell.net> wrote:
    >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.)
    >> >
    >> >

    >>

    >
    >



  6. #6
    ian drake Guest

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


    Rob -

    Did you check out the site I was refering to? I quess I'm not clear on if
    you were arguing with me or against me, because I agree with what you are
    saying, I assume your arguing with me.

    On the site it was saying that the BLL was all in one file, which would make
    it impossible for 2 developers to work an the same source code with VSS.
    I was saying that the BLL does not have to be in one file, and really shouldn't
    be. You can put all you 20 classes in one file or you can put 20 classes
    in 20 files. I'd do the latter. It sounds like you would to.

    You refered to decentralized code as being a nightmare to updata/fix, and
    I agree with that, it was one of my arguements. The other fellow(I didn't
    catch his name), is saying that the IDE should track and manage snippets
    of Business logic mixed withing all the code behind classes. Sounds like
    a bad idea to me.

    Ian

  7. #7
    com no spam lift Guest

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


    "ian drake" <ian.drake1@home.com> wrote in message
    news:3a2e864d@news.devx.com...
    >
    > I see now what you are suggesting. I guess it comes down to which of the
    > following statements you agree with:
    >
    > 1. It is the job of the IDE to logically group, track and manage business
    > logic code.
    >
    > 2. It is the job of the developer to logically group code into objects

    that
    > can be reused from many different places.
    >
    > In some aspect I can see your point. Being able to see all the code that
    > is getting run is a convience that you don't have in OO. You find

    yourself
    > constantly following the path of logic. Diving into classes that you

    didn't
    > write to find the guts of what the **** it's doing. Many times having to
    > go several levels deep. Let's face it, must components developed in house
    > are not black boxes, nor documented.
    >
    > But I couldn't give relinquish the responsiblity of my logical code

    mangement
    > to the IDE. I like the OO approach, and although frustrations can arise,
    > I think most people like it too.
    >


    I can see how you couldn't relinquish the responsibility of your logical
    code management to the IDE; However, I am thinking if the VS.NET IDE is done
    right, it can at least help guide programmers as it takes many, many pieces
    to make an enterprise web site. Another thing is that you might look at
    code now and then forget about it the next day. Then the Sales team needs a
    change 3 months from now and you have totally no idea what you did 3 months
    ago.

    This I hope can make it faster and easier. sort of like enhance comments
    with a few extra options to make changes across the web site, yet having a
    Master Undo Feature, Hmmm wouldn't that be great as I think Source Control
    should be that easy to implement and learn.




    > ian
    >
    > "com no spam lift" <com_no_spam_me_lift_jose8@pacbell.net> wrote:
    > >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.)
    > >> >
    > >> >
    > >>

    > >
    > >

    >




  8. #8
    com no spam lift Guest

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




    "ian drake" <ian.drake1@home.com> wrote in message
    news:3a2e8965$1@news.devx.com...
    >
    > Rob -
    >
    > Did you check out the site I was refering to? I quess I'm not clear on if
    > you were arguing with me or against me, because I agree with what you are
    > saying, I assume your arguing with me.
    >
    > On the site it was saying that the BLL was all in one file, which would

    make
    > it impossible for 2 developers to work an the same source code with VSS.
    > I was saying that the BLL does not have to be in one file, and really

    shouldn't
    > be. You can put all you 20 classes in one file or you can put 20 classes
    > in 20 files. I'd do the latter. It sounds like you would to.


    Looking at IBuySpy for example, It's got 6 business modules. However just
    because you split it up into,
    Business Components
    a.. ProductsDB.vb
    b.. ShoppingCartDB.vb
    c.. CustomersDB.vb
    d.. OrdersDB.vb
    e.. ReviewsDB.vb
    f.. IBuySpyDB.vb
    You could still have 2 programmers needing to work on like OrderDB.vb even
    though all of the classes are split into 6 modules. Just because you have 6
    files doesn't mean that 2 programmers will not need access to the same file
    at the same time. Maybe less of a chance, but I can Murphy's Law coming
    into play here as it always does.

    If you were going to have 20 classes into 20 files then you should just have
    the classes in each code behind file which is a separate class.

    >
    > You refered to decentralized code as being a nightmare to updata/fix, and
    > I agree with that, it was one of my arguements. The other fellow(I didn't
    > catch his name), is saying that the IDE should track and manage snippets
    > of Business logic mixed withing all the code behind classes. Sounds like
    > a bad idea to me.
    >
    > Ian




  9. #9
    ian drake Guest

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


    It is certainly not a classical approach, but I could see that it could be
    useful. Still, you shouldn't hold your breath for anything like that to
    come out of microsoft, ever.

    ian

  10. #10
    Rob Teixeira Guest

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


    Sorry bud,
    I wasn't arguing with you - or against you, I was agreeing with you

    "ian drake" <ian.drake1@home.com> wrote:
    >
    >Rob -
    >
    >Did you check out the site I was refering to? I quess I'm not clear on

    if
    >you were arguing with me or against me, because I agree with what you are
    >saying, I assume your arguing with me.
    >
    >On the site it was saying that the BLL was all in one file, which would

    make
    >it impossible for 2 developers to work an the same source code with VSS.


    Two developers can in fact work on the same file in VSS. However, VSS then
    needs to merge changes from multiple sources, and I've never trusted that
    feature (actually, i don't trust developers to work on the same file and
    not screw up something someone else was doing). I'd rather have exclusive
    checkout turned on. Just because the same functionality needs to be accessed
    in multiple locations within the project does not mean multiple developers
    need to be working on the same code at the same time.
    Think of it in these terms: There are textboxes everywhere in Windows. The
    majority of app/dialog windows have at least one. Would you have textbox
    code in every single window? Of course not. You would create a textbox component
    that everyone else can use.
    Which is exactly how it works.
    More about this in the following comments...

    > I was saying that the BLL does not have to be in one file, and really shouldn't
    >be. You can put all you 20 classes in one file or you can put 20 classes
    >in 20 files. I'd do the latter. It sounds like you would to.


    To me it's not a matter of putting everything in one file or putting everything
    in seperate files. Splitting the files should be done intelligently with
    implementation and maintenance reasons as the criteria.
    Componentization is the key to centralizing and keeping developers from stepping
    on each other's toes.

    >You refered to decentralized code as being a nightmare to updata/fix, and
    >I agree with that, it was one of my arguements. The other fellow(I didn't
    >catch his name), is saying that the IDE should track and manage snippets
    >of Business logic mixed withing all the code behind classes. Sounds like
    >a bad idea to me.


    So what happens when multiple IDE's are affecting the same code? I would
    feel safer with VSS and not pawning off that work to the IDE. So we're in
    agreement there too.

    -Rob

  11. #11
    ian drake Guest

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


    Rob,

    By saying arguing with me, I meant agreeing with me, as in two people arguing
    a point against one person. It made alot more sense in my head. Anyway
    I meant to put in a way that meant we were in agreement.

    I never use merge too, that is why I just say that two developers can't work
    on the same page in VSS. Just like I would say that you can't tight rope
    walk from the top of one trade tower to the top of the other trade tower.
    You could, but you'd be asking for trouble.

    Anyway, I just wanted to clear that up.

    ian

  12. #12
    com no spam lift Guest

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

    I didn't think you were argueing with me, I just want to add more info and
    be more clear.

    Thanks for the input.


    "Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
    news:3a2e972e$1@news.devx.com...
    >
    > Sorry bud,
    > I wasn't arguing with you - or against you, I was agreeing with you
    >
    > "ian drake" <ian.drake1@home.com> wrote:
    > >
    > >Rob -
    > >
    > >Did you check out the site I was refering to? I quess I'm not clear on

    > if
    > >you were arguing with me or against me, because I agree with what you are
    > >saying, I assume your arguing with me.
    > >
    > >On the site it was saying that the BLL was all in one file, which would

    > make
    > >it impossible for 2 developers to work an the same source code with VSS.

    >
    > Two developers can in fact work on the same file in VSS. However, VSS then
    > needs to merge changes from multiple sources, and I've never trusted that
    > feature (actually, i don't trust developers to work on the same file and
    > not screw up something someone else was doing). I'd rather have exclusive
    > checkout turned on. Just because the same functionality needs to be

    accessed
    > in multiple locations within the project does not mean multiple developers
    > need to be working on the same code at the same time.
    > Think of it in these terms: There are textboxes everywhere in Windows. The
    > majority of app/dialog windows have at least one. Would you have textbox
    > code in every single window? Of course not. You would create a textbox

    component
    > that everyone else can use.
    > Which is exactly how it works.
    > More about this in the following comments...
    >
    > > I was saying that the BLL does not have to be in one file, and really

    shouldn't
    > >be. You can put all you 20 classes in one file or you can put 20 classes
    > >in 20 files. I'd do the latter. It sounds like you would to.

    >
    > To me it's not a matter of putting everything in one file or putting

    everything
    > in seperate files. Splitting the files should be done intelligently with
    > implementation and maintenance reasons as the criteria.
    > Componentization is the key to centralizing and keeping developers from

    stepping
    > on each other's toes.
    >
    > >You refered to decentralized code as being a nightmare to updata/fix, and
    > >I agree with that, it was one of my arguements. The other fellow(I

    didn't
    > >catch his name), is saying that the IDE should track and manage snippets
    > >of Business logic mixed withing all the code behind classes. Sounds like
    > >a bad idea to me.

    >
    > So what happens when multiple IDE's are affecting the same code? I would
    > feel safer with VSS and not pawning off that work to the IDE. So we're in
    > agreement there too.
    >
    > -Rob




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