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

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