280 reputation
18
bio website
location
age
visits member for 3 years
seen Jul 24 at 2:57

Jul
22
comment Should I use the repository in the Domain Object or push the Domain Object back to the Service Layer?
My domain objects are not the Entities, so adding them to the Licenses collection, which is just a List will not cut it. The question is not so much about EF though as it is where the actual persistence takes places. All persistence in EF must take place within a context scope. The question is where does this belong?
Jul
22
asked Should I use the repository in the Domain Object or push the Domain Object back to the Service Layer?
Jun
18
answered How to transition from “help vampire” to “developer”?
Jun
4
awarded  Yearling
Jun
4
awarded  Teacher
Jun
4
answered Is ASP.NET MVC too much overhead for smaller projects?
Jun
4
comment Does a programmer really need college?
Sounds like UK is similar to Australia: a degree is regarded as a piece of paper to get you your first job, after that people only ever care about work history. I never take my academic record to job interviews and have never asked to see a candidates when hiring. In fact no one ever asked to see my degree for my first job position!
Jun
3
comment Significant amount of the time, I can't think of a reason to have an object instead of a static class. Do objects have more benefits than I think?
+1 especially for points 3 and 4. Interfaces, Interfaces, Interfaces.
May
26
comment Exceptions or Error codes
It past projects we never used Exceptions in code or Faults in SOAP to communicate legitimate/expected modes of failure. We used error codes and left them up to the client to decide what to do with them. User not found is not really an error/exception, this should probably be a status code.
May
18
awarded  Commentator
May
18
comment Dividing responsibilities between client and server
+1 for "we ought to perceive the Angular front-end as a View-Controller. Don't use models in the frontend, use services."
Apr
2
awarded  Peer Pressure
Nov
11
accepted What layer to introduce human readable error messages?
Nov
6
comment What layer to introduce human readable error messages?
I also worked on one Silverlight project where the team was using Restful WCF. The approach they took was to use error codes and store the messages in a resource file embedded in the Silverlight client. The application spec required localization and by keeping all human readable information right in the client they were able to free the database completely from localization concerns. This is now the way I am thinking...
Nov
6
comment What layer to introduce human readable error messages?
MVC/MVVM/MVP are way over at the UI end of the spectrum. I am really talking about a pattern for returning error information from an API, regardless of the type of client. The "client" may be for example a Windows Service that uses the API, but has no need at all for human readable messages. It could be that the API is exposed by a WCF SOAP service in which case there is no telling what type of client will be remotely consuming the API. "I would send the message along with the response from the server to the client." This is pretty much a "result object" approach isn't it? Data+Message.
Nov
6
comment What layer to introduce human readable error messages?
I don't disagree, but I think logging is a distinctly different issue.
Nov
6
asked What layer to introduce human readable error messages?
Jan
23
comment So Singletons are bad, then what?
First post I have ever read which actually explains DI as an alternative to global state. Thanks for the time and effort put into this. We are all better off as a result of this post.
Aug
1
comment Why can't the IT industry deliver large, faultless projects quickly as in other industries?
Many large projects like the F-35, Hubble Telescope, etc were late because of the software side of development. The Hubble actually sat in storage for years because the software was not ready.
Jun
8
comment Is it getting harder to hire VB.NET developers?
This comment is exactly what I am thinking and have experienced. I have worked with both C# and VB.NET developers over the last about 7 years and I have found major differences between them. VB.NET guys just don't get OO, they don't get Interfaces, they don't get loose coupling and they think it is fine to code 8000 lines of logic in the code behind of their Winforms. I think this ultimately comes from their VB Classic background, whereas C# guys generally come from a C++ background. It is from these experiences that I always prefer applying for C# positions over VB.NET...