I was surfing the net this morning and found this in one forum. The author seemed clueless of what he's talking about. I'm not sure if I'm going to irritated or laugh (out loud)...I just find it pathetic...see for yourself
here.
As a regular member of the local MS forum here in our place, I felt that I am always the "bad guy" when answering post. Well maybe because I am a new comer unlike most of the people there. I always got flamed when opposing to these ideas: Architecture - That having the connection string in the client (Win Form) or putting all those SqlCommands in the UI (Web/Win) is the correct way of doing things. - That using a WEB SERVICE to manage/centralize the connection string is the way to go. - That SQLHelper ......
Imagine your business entities would be something like this: public string Firstname { get { LoadInfo(); return _firstname; } set { LoadInfo (); if (_firstname != value) { _firstname = value; ExecuteQuery("UPDATE Table SET Firstname = '" + _firstname + "' WHERE ID = " + _id.ToString()); } } } public string Lastname { get { LoadInfo(); return _lastname; } set { LoadInfo (); if (_lastname != value) { _lastname = value; ExecuteQuery("UPDATE Table SET Lastname = '" + _lastname + "' WHERE ID = " + _id.ToString()); ......
I will call this the "PowerBuilder Pattern" coz this was based on an existing PowerBuilder ancestor design of one company. I was shocked when they told me about this design to be implemented in .Net. Cheers! :-)
What I learned from reading other .Net blogs was not to focus on MS Architecture patterns alone but, to also read other architecture patterns like this - J2EE Transfer Object pattern. I got this site from Frans Bouma, who recommended this link, in Paul Wilson's blog entry about Avoiding Reflection ......