Comments for .NET and me

Comment on Silverlight Data Pager, fake ItemsCount and stored procedures by Cecil R. Woods

Cecil R. Woods — Thu, 17 Jan 2013 18:15:43 +0000

The purpose of a DAO layer is that your application not have any notion of what your persistence mechanism is, or even that things are persisted. It’s a layer of abstraction that gives you flexibility down the road.I’ve relied on this twice in my career. Once was moving a component using Oracle to use a completely different schema (but same object model) in PostgreSQL, and the second was moving from an LDAP directory to an Oracle database (once again, keeping the object model.)Without the DAO abstraction, these projects would have needed substantial work, with a lot of testing. With the DAO pattern, we just wrote new DAO interface implementations, changed the DAOFactory settings, and the app sitting on top of it just plain worked. We didn’t need to test anything other than the queries, because that’s all that changed.If you have a frozen platform and simple ORM using a tool is fulfilling your need, then DAOs might be overkill. But if you ever need to make some major changes, any time spent creating a “redundant” DAO layer will be bought back four or five times.Oh and as for performance, trust me when I say that having to call a DAO that calls an ORM method is not going to make an appreciable difference in your response time when compared to calling the ORM method directly. If you were that worried about performance, you might optimize the SQL yourself, instead of using a mapping tool.

Comment on How to do multiple inheritance in C# – Implementation over delegation (IOD) by Mahesh M

Mahesh M — Tue, 19 Apr 2011 13:38:30 +0000

Hi Thomas,

This is really good example of Jedi sample.
Still it has kind of dependency
like while instanciating jedimaster we need to know about instance of lightinghand and hence i think it is kind of dependency injection. still it does not solves the contravarience problem (i.e converting from jedimaster to lightinghand

but in the example above we can solve the issue as explain below;
IClassB interface = new MyUserControl();

correct me if i am wrong since I am not master in OOPS.

Regards,
Mahesh M

Comment on Say no to ServiceLocator by The Service locator pattern is evil | Tom de Koning

The Service locator pattern is evil | Tom de Koning — Mon, 04 Apr 2011 15:25:43 +0000

[...] are many references why this should be avoided (see here, here and here) , but I think the one reason why you should not do it is testability. You should be able to mock [...]

Comment on 5 reasons why Silverlight sucks in LOB (compared to WPF) by chris

chris — Sat, 02 Apr 2011 06:50:09 +0000

u r right.. runs only on mac nd windows & windows phone i guess… @present we have android nd other new linux versions getting more popular..
wish SL version 5 is platform independent …

Comment on Model View Presenter (MVP) VS Model View Controller (MVC) by st.clouds

st.clouds — Thu, 31 Mar 2011 15:24:29 +0000

Ignore 115.111.36.98, we know he’s an idiot.

I do think there’s a lot more modularity that can be achieved using WCSF. It’s a really good framework. So many tools and options also open up to you and you can achieve much better cohesion than you can with MVC (admittedly my biggest complain about it atm).

Very good observation with convincing architectural argument.

Comment on TDD – Rhino Mocks – Part 2 – Some common scenarios by KD

KD — Wed, 23 Mar 2011 04:26:48 +0000

Really a nice blog explaining exactly what i was looking for….
It really helps new learners to get the exact scenario about rhino mocks….
Thanks for posting..

Comment on Asking the right questions while interviewing developers by tcmaster

tcmaster — Sat, 19 Mar 2011 14:34:08 +0000

Me too. I DISagree the example has anything to do with the way memory is used. It’s how the compiler handle the virtual methods.
The default .net compiler will put (in most cases, but not always. where the int in a class put?) value types in heap, and ref type in stack. But no one prevents you from writing a compiler which does not have even concept for stack and heap. But if you want it to be C# compatible compiler, it must behave the way when it meets virtual methods.

Comment on Naked MVVM–simplest possible MVVM approach by Siderite

Siderite — Sat, 05 Mar 2011 20:27:07 +0000

Damn it, Andre Luus, I was going to try to seem smart by linking to Rob Eisenberg’s talk and you got there first. At least I get to point out that you mispelled his name

Comment on Model View Presenter (MVP) VS Model View Controller (MVC) by Nikola Malovic

Nikola Malovic — Fri, 04 Mar 2011 10:38:13 +0000

Steve/Faye/Sangram,

how impressive is that someone is so dumb to post 3 comments on the blog with the same IP adress (115.111.36.98) using different names and same broken english?

Not sure why you insist insulting me when I don’t disrispect you at all in, but I’ll take that as a sign of your own personality and would leave all of your comments published so other can see what type of person you are trully.

Thanks,
Nikola

Comment on Model View Presenter (MVP) VS Model View Controller (MVC) by Nikola Malovic

Nikola Malovic — Fri, 04 Mar 2011 10:33:09 +0000

Faye,

If you read my answer to him you can see that I also think MVC is better for web development.
I am calm – he and you are the ones who insult others calling them dump (btw, it is dumb not dump).

Nikola
PS:”Free PR advice: If you are going to insult other people on their blogs for their personal oppinion they publiclly shared with community, at least sign yourself with your full name and surname. It would look less cheesy.”