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

[com no spam lift]

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

[ian drake]

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

[com no spam lift]

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

[Rob Teixeira]

"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

[ian drake]

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

[ian drake]

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

[com no spam lift]

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

[ian drake]

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

[com no spam lift]

"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

[Rob Teixeira]

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

[ian drake]

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

[com no spam lift]

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