Sometimes the simplest things can be the coolest. I just stumbled onto this today, I cannot believe I did not know about it before (or if I did, I had forgotten).

In C#, in addition to simply importing a namespace into a code file (“using” directive), you can also define an alias for it. Why is this cool?

A hypothetical project uses assemblies from two vendors. For argument's sake lets say the two vendors are just seperate departments in your organization. Both departments maintain their own business object classes, in their own namespaces:

namespace MyCompany.Accounting.BusinessClasses {...}

and

namespace MyCompany.Shipping.GlobalDataClasses.Core {...}

Now, it doesn't really matter what the actual namespaces are for this discussion, just that they are a pain in the ass to type, and they both contain a class of the same name (”Company” in this example).

Now, supposing we work for the Accounting department and we are asked to write a peice of code that can find and update a corresponding Shipping account record when someone in Accounting saves a change on our side. We would likely end up with something like this...

using MyCompany.Accounting.BusinessClasses;
using MyCompany.Shipping.GlobalDataClasses.Core;
<...>
MyCompany.Accounting.BusinessClasses.Company Destination = MyCompany.Accounting.BusinessClasses.Company.FindCompany(company_id);

MyCompany.Shipping.GlobalDataClasses.Core.Company Source = new MyCompany.Shipping.GlobalDataClasses.Core.Company(company_id);
<... do some stuff with both objects ...>

Now that's enough verbosity to make the baby Jesus cry! Having to inline those namespaces in the code makes it VERY painful to read, and the only reason we have to do it is because otherwise the type name “Company” would be too ambiguous.

Well, Namespace Aliases gives us a way to “pretty up” this code. We can assign an alias to each namespace import, which can then be used in the code as an abbreviation:

using Acct=MyCompany.Accounting.BusinessClasses;
using Ship=MyCompany.Shipping.GlobalDataClasses.Core;
<...>
Acct.Company Destination = Acct.Company.FindCompany(company_id);
Ship.Company Source = new Ship.Company(company_id);
<... do some stuff with both objects ...>

Fantastic!

One other thing to mention is that when you alias a namespace like this, you can no longer directly reference classes from that namespace without a qualifier. For example:

using Data=System.Data;
<...>
DataSet MyDataSet1 = new DataSet(); // <-- this will not work when System.Data is aliased!
Data.DataSet MyDataSet2 = new Data.DataSet(); // <-- this will work

What you can do to fix this is to import the namespace twice. Once using the alias, and once without an alias. This gives us the best of both worlds:

using Data=System.Data;
using System.Data;
<...>
DataSet MyDataSet1 = new DataSet(); // <-- this will work now!
Data.DataSet MyDataSet2 = new Data.DataSet(); // <-- this will still work

 

Cool stuff!!! I love learning new simple language features I should have known about 2 years ago!!

 

OK, I will most likely regret this post at a later time, but oh well...

Is it just me, or do others become more productive with coding after a few brewskies? Here it is 1:15 AM, I just polished off over half a bottle of wine, and I feel like I could knock out a ream of bugs/changes. I have already done more work in the last 2 hours while drinking than all of the previous day while sober. And I feel like I am just getting started.

What's up with that?

Too bad most employers wouldn't agree to supplying a few beers during work hours to boost productivity.

 

I usually do not get excited about reporting engines. In fact, I generally detest them.

But today I got a call from my last active client who is still using Crystal Reports, and they just approved the migration over to SQL Reporting Services. I am thrilled. I cannot wait to get that Crystal garbage out of their applications.

I never thought I would be happy to be rebuilding reports, but here I am... eager to get started on that process. Just have to wait until I get a couple other minor modifications completed first...

 

FAQ: When do I use Remoting and when do I use WSE/ASMX?

Rockford Lhotka does a great job explaining how to go about making this decision. The only thing I would add is that in large enterprise systems, the boundaries bewteen subsystems should also be considered as a good candidate for message-based interfacing like WSE.

 

I had an email exchange today on the topic of O/R mappers and model-driven code-blowers and related discussion. The topic seems to resurface often enough at user groups (and the “pub meetings” that often follow) to merit jotting down my personal position on it here. While I am certainly not the definative expert here, I feel I have “been there, done that“ enough to formulate a fairly defensible and reasonable opinion of the matter.

This discussion in particular was triggered when a friend of mine sent me a link to this free code-blower engine from a Microsoftie in France: http://www.microsoft.com/france/msdn/olymars

***Please note that I in no way endorse or discredit any way of designing a DAL, or any product (free or otherwise) that may be used to such an end...

-------------------

My observations:

There are 4 basic camps of folks, each sure they are right and all others are wrong.

Camp 1) O/R Mapping is better than sliced bread. Everyone needs to use it. There is nothing wrong with basing business processing components on ORM-aware components.

Camp 2) O/R Mapping is the devil. Code-blowing is the answer. Kill all the ORM people. Business components should be based on the metadata-driven basic entity components, extending their raw data storage capability (the generated part) with program logic (generally using OOP inheritance).

Camp 3) ORM and Code-blowing are both silly wastes of time. Just slam all your data access code together with your business processing and be done with it. If it's a web site, then just pack it all into the page code too if you are “smart“ enough to be able to work with it.

Camp 4) Use ORM -or- Code-blowing to build a “problem domain-specific” data-access interface. Keep it seperate from your business processing, making calls back from the business code through the data-access interface.

O/R Mapping is sometimes referred to as "object-driven database design". Code-blowing is often referred to as "model-driven object design". Each having their own merits and shortcomings.

Camps 1 and 2 are quite similar, they focus too much on the fine-grained detail in lieue of the greater picture. They can't see the forest for the trees, and end up re-inventing the forest for nearly every project.

Camp 3 folks tend to also strongly support the "Agile/extreme Development" way of building systems. They like to fly by the seat of their pants.

Camp 4 tends to be where people eventually gravitate towards, given enough experience with the other 3 methods. I myself started out in Camp 3, briefly tried Camp 1, and recently spent a good bit of time in Camp 2. I now feel Camp 4 offers the best flexibility and meets business needs better.

I really don't want to give a hoot whether my DAL is using ORM or metadata-driven semantics. All I care about is that -something- is taking care of sending the data to the correct place in the database, and as long as my interface to that mechanism meets the business needs at hand, its irrelevant what technology handles it from there.

In the end, I currently favor using ORM or Code-blowing (or some other form of automation) to assist in construction of a strongly-typed per-application/service data interface, and then making calls to this interface from the business components. They should not care about the intricacies of database manipulation, nor should they care how such manipulation is being performed (ORM, etc). As long as the business component can request “field A“ in “table B“ be assigned a “value X“, it does not matter if the work is being done with O/R mapping, standardized stored procedures, ad-hoc SQL, or any other mechanism. All those concerns have zero business value in the end, and only serve to get in the way of solving business problems.

Michael Zalewski started feeding randomly malformed HTML into Microsoft Internet Explorer, Mozilla, Opera, Lynx, and Links and watching what happened. Bottom line: 'All browsers but Microsoft Internet Explorer kept crashing on a regular basis due to NULL pointer references, memory corruption, buffer overflows, sometimes memory exhaustion; taking several minutes on average to encounter a tag they couldn't parse.'

http://slashdot.org/article.pl?sid=04/10/19/0236213

 

I get asked this question a lot, although sometimes what people are really asking is "What does it mean to be a contractor".

I read a recent post from Ted Neward that implied perhaps we are taking the Ws-* suite of specifications too far. Specifically, the question of:

“at the end of the day, are we really just reinventing TCP/IP?“

I thought about this question today, and my conclusion is that Yes, in a way, we are. But it is not over the top. We are reinventing the routability nature of TCP/IP addressing. We are also reinventing the addressibility of DNS (which is essentially a redirection layer on top of tcp/ip).

However, this reinvention is indeed necessary in the new scheme of things. You see, TCP/IP and DNS were designed for a world in which always-connected and seldom-rerouted data channels were the norm. Everything was point-to-point, the network infrastructure was expected to maintain this for us. We have since learned through trial-and-error that 1) we cannot depend on the infrastucture, and 2) we need adaptability in the infrastructure. Basic Tcp/Ip and DNS do not accomodate those very well. And this is why we need the additional layers of WS-Addressing, and other related WS-* in a SO world.

I should also point out that the new “infrastructure“ WS specs (routing, addressing, etc) are not necessarily tied to hardware tcp/ip stacks. Sure, right now this is our standard mode of transport, but it does not have to be. This is a good thing as it does not force us to rely on tcp/ip networking forever. What if the next generation networking platform does not even use tcp/ip? It's not that far-fetched... after all, tcp/ip was not always the king of networking protocols.. and many network systems do not do tcp/ip natively (they just imitate it). ATM, wireless, cellular, these all use cell-based protocols which are better suited for larger payloads than tcp/ip, and they just let tcp/ip piggyback on top in order to provide interoperability with the internet at large. Hmm... high efficiency/speed ATM SOAP routing... thats an interesting possibility...

It seems a lot of folks have been questioning these particular peices of the WS specs lately. I hope they start to realize that these are very important in the grand scheme of what it means to build SOA systems.

The days of being able to segment a data packet into chunks and only sending along the destination IP in the header (which in a nutshell is all tcp/ip does) are over. System interfaces have matured beyond that simplistic model, and now its about time our messaging infrastructure matured beyond it as well.

Viva la WS stack.

At least until the next great layer of data routing is invented...