ASP.NET 2.0 Security... Damages Layer Separation

I have been reading about "The Demise of the Security Application Block" and I quote:

"Specifically, the factories, interfaces and providers for authentication, roles and profile have been removed. Equivalent functionality is provided by the new System.Web.Security.Membership class and System.Web.Profile namespace."

I think that is a really big mistake architecturally speaking... why? well because System.Web.Security.Membership class and System.Web.Profile are for
WEB applications, not for WindowsForms.NET applications, and authentication and authorization should be services independent of the presentation
mechanism, the Security Application Block should wrap the System.Web.Security.Membership class and System.Web.Profile namespace functionalities
and allow the developer to work in a presentation independent way (or Microsoft should change System.Web.Security.Membership class and System.Web.Profile and make them
System.Security.Membership class and System.Profile)

I think the easier thing to do is to bring back the the factories, interfaces and providers for authentication, roles and profile of the Security Application Block that provided this services without violating layer separation (following the good example of JASS).

And perhaps, in the future the "revived" Security Application Block should be merged with .NET code... or a new presentation independent API named ".NET Authentication and Authorization Service" (NASS?) should be created...

What do you think?

Layer Separation Violation: Web Configuration Manager... one of ASP.NET 2.0 mistakes?

The management of configuration in .NET applications was improved in .NET 2.0, now it is easier to have custom configuration sections, and we even have pre-built configuration section for Connection Strings (very useful for ADO.NET applications)

But... there are some design decisions I just don't get... "Configuration" is a separate concern from presentation (configuration can be used to set UI behavior, but in my opinion, configuration is in a lower layer), but now we have the WebConfigurationManager for web applications and the ConfigurationManager for client applications ...

From MSDN website:

Using WebConfigurationManager is the preferred way to work with configuration files related to Web applications. For client applications, use the ConfigurationManager class.

First, I thought... "this is going to be a problem", now I won't be able to read configuration in the lower layers (business facade, business rules, data access) without having to use my own proprietary "trick" to hide the fact that for those layers it is irrelevant whether the application has a WebUI or a WinUI... how could the .Net team make such a bad decision?

But then I realized... that i can use the ConfigurationManager from an WebUI (ASP.NET Application) without any problem... so my lower layers don't suffer from contamination from the presentation mechanism...

But now i am wondering... If the ConfigurationManager works perfectly... and doesn't tie my code to a particular presentation code... why should I use the WebConfigurationManager.... in fact... why should anyone use the WebConfigurationManager ? I just haven't figured out that...

The Tao of the Software Architect

Today I read about the Software Architect role in the SEI website, and I found a lot of very useful information:

• Books that an architect should read
• Essays
• Ways to become certified or accredited as a person than can create or evaluate architecture.

And, the essay that I liked the most was "The Tao of the Software Architect" (That can also be found in IBM website)

From the "The Tao for the software architect" I specially liked this part:

When the process is lost, there is good practice.
When good practice is lost, there are rules.
When rules are lost, there is ritual.
Ritual is the beginning of chaos.

I have seen places where ritual has taken control of everything, and people there believe they are doing things right, because they are following the ritual, but they don't realize that they are in chaos,  because they no longer understand why are they doing what they do... and that is really bad, because they don't look for ways to get out of the chaos, because they think that what they do is fine, because they are following the ritual (even if the ritual  doesn't achieve anything valuable for the organization)

Another part i also liked a lot is this:

If you want to be a great leader,
stop trying to control.
Let go of fixed plans and concepts and
the team will govern itself.
The more prohibitions you have,
the less disciplined the team will be.
The more you coerce,
the less secure the team will be.
The more external help you call,
the less self-reliant the team will be.

I believe I have that problem, sometimes I become a "control freak" and want everything to be built the way I say it, in the time I say it, exactly as I say it... but, as I gain experience I am starting to realize that is not the way to build a system, to be a good architect I have to help set a process that will be used to build the system, and make sure that the process is followed and that the processes evolves with the team and the system being built and at the same time get out of the way and let the team flourish...

As with most of this Zen-like things.. the truth is somewhere in the middle:

Too little control and you will have chaos, too much  control...specially just for the sake of following the ritual... and you will negatively affect the team motivation, creativity... and productivity.

I guess I need to find the Middle Path for Software Architecture...

Administering an ASP.NET WebSite

Hi! One of my friends showed me how to access the ASP.NET Administration WebSite without calling it from within VS.NET:

• Create a virtual directory ASP.NETWebAdminFiles in IIS that point to C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ASP.NETWebAdminFiles

• Open properties windows of the new virtual directory, make sure that it is configured to run with ASP.NET 2.0, and in Security tab, uncheck Anonymous Access, check Integrated Windows Authentication. After that, you will be able to connect to WebAdminTools using the following syntax http://localhost/ASP.NETWebAdminFiles/default.aspx?applicationPhysicalPath=XXX&applicationUrl=/YYY in my case, it is: http://localhost/ASP.NETWebAdminFiles/default.aspx?applicationPhysicalPath=D:\Tasks\Libranyon\Photonyon\&applicationUrl=/Photonyon

Although I don't recommend to do it, if you want to access WebAdminTool from other computer, open WebAdminPage.cs from (C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\ASP.NETWebAdminFiles\App_Code) and comment the following code block

if (!application.Context.Request.IsLocal) {

SecurityException securityException = new SecurityException ( (string) HttpContext.GetGlobalResourceObject( "GlobalResources", "WebAdmin_ConfigurationIsLocalOnly" )); WebAdminPage.SetCurrentException(application.Context, securityException); application.Server.Transfer("~/error.aspx");

}

WebAdminTool still be protected by Integrated Windows Authentication, so you still some have some defense here. I have found this same instructions here, so I guess my friend got them from there.

Refactoring Bug in VS.NET 2005

Every time you modify the name of an element in a webform, it triggers refactoring
and checks all the project... and that is just plain not necessary... it is a
really really annoying bug! Perhaps they will fix it in a future release.... I just
hope I could turn off all VS.NET refactorings... (and let Reshaper do the job)

Extreme Normal Form

Today I read about "Extreme Normal Form"... and well I really liked it:

Your classes are small and your methods are small;
you've said everything OnceAndOnlyOnce and you've removed the last piece of unnecessary code.
Somewhere far away an Aikido master stands in a quiet room.
He is centered.. aware.. ready for anything.
Outside a sprinter shakes out her legs and settles into the block, waiting for the crack of the gun while a cool wind arches across the track.
Softly, a bell sounds.. all your tests have passed.
Your code is in ExtremeNormalForm... tuned to today and poised to strike at tomorrow.

I also liked a lot OnceAndOnlyOnce balances YouArentGonnaNeedIt. I have never liked the idea of applying YouArentGonnaNeedIt by itself, but now I believe that by using OnceAndOnlyOnce a good balance can be achieved. Read it here

OMG: Object Orientation and Stored Procedures

OMG! how many times have I read the argument "using stored procedures is object oriented programming" just think of the database as an object, and think that each stored procedure is an method of the database....
Now... I am not going to say that using stored procedures is wrong... and I am not going to say that the only correct way of solving software problems is using object orientation... ( I do prefer to use object orientation, I a do prefer to use an object relational mapper instead of a stored procedures, specially for OLTP applications, I think application built that way are more maintainable, more portable between database, can be built faster, scale better, etc,etc)

But for batch processing, stored procedures have a clear advantage, and in my experience many business problems are solved by using an OLTP application, and a short but very important list of batch process... (of course the problem here is that if you built you application using an ORM, probably you have a lot of you business logic already implemented in a presentation-independent form, and, depending on the size of you database, you could program you batch process using your business objects... that has its disadvantages (slower performance that stored procedures) and its advantages (reutilization)... I believe reutilization and maintenance are more important that performance... specially because it is possible to worry about performance in the wrong way: for example Premature Optimization )

But the main point of this post, is that, first, I didn't think that using stored procedures was object oriented programming... it was "procedural programming"... or perhaps even "relational programming" but certainly not object oriented programming (where is the inheritance? where is the polymorphism?) but... after giving it some more thought... I realized that while it could not be "object oriented" it could be "object based"... stored procedures can encapsulate your tables (one of the major advantages of stored procedures) and you can see them as methods to a your "database" object...

So... now... your (OLTP?) system is a thin presentation layer on top of the "database object"... now... is there something in favor... or against that in object oriented design theory?.... mmm.... it achieves Presentation/Business Logic separation... and that is good... but I still feel there is something that doesn't feel right...

OMG! Well, it turns out there is! : Now the database is a God Object.
From Wikipedia: A God object is an object that knows too much or does too much. The God object is an example of an anti-pattern, it goes against divide & conquer ... using a God object is analogue of failing to use subroutines in procedural programming languages, because so much code references it, it makes maintenance difficult...

So... the next time someone tells you that using stored procedures is good object oriented programming... you could answer him or her: Oh My God (Object)! (You could think of it as object based, but, form an object oriented point if view.. it is a recommended solution? couldn't it be seen as an anti-pattern? I am not saying it is wrong, I am just saying that from an object oriented point of view, it might not be the best way to solve the problem... of course, using object orientation might not be the right way to solve this particular problem, after all, object orientation is not a Silver Bullet)