412 reputation
415
bio website
location
age
visits member for 4 years, 1 month
seen May 23 at 0:25

May
19
comment How do you avoid getters and setters?
Why do you assume that article is nothing but 100% BS?
May
17
comment Detecting and Dealing with obscene language in user input
"What method should I use to detect and handle obcene language in user input without restricting conversation". Sounds like a contradiction to me. You want to restrict conversation without restricting it.
May
16
comment Why is build.number an “abuse” of semantic versioning?
" you have version 5.7, and you want to patch it to 5.7.1, but your first 2 bugfixes fail to build when they are submitted to the CI system, then you will be at 5.7.3 before you've released your first patch!" ok, but so what? I don't recall anything in semver saying the numbers must not skip.
May
9
comment Will a computer science college degree ever hurt my employability?
A degree from a good university can only help.
May
9
comment Build automation vs deploy automation vs continuous integration
It builds on my machine isn't good enough as it relies on revs to do the right thing every time. Things like new dependencies or other team member changes combined with yours now breaks a test.
May
9
comment Build automation vs deploy automation vs continuous integration
@Skahrz if you want automated deploys you have options like BuildMaster (also a CI server) and Octopus Deploy.
May
8
comment Should Software Engineering and Computer Science be separate majors?
What makes you think they aren't? RIT offers both as degrees.
May
6
comment Should a domain object wrap/contain a DTO interface?
Validation elsewhere leads to anemic models. While a subclass per data access probably isn't the way to go, neither is using an orm to map the domain model. When it comes to data access, the choice is usually SRP vs. encapsulation. Given that choice, I'll choose to keep encapsulation.
Apr
24
comment Why is a architecture with anemic models the JavaEE standard?
@Oscar agree, you would not directly expose your domain model with a web service. You'd do just as you said, with the service built on top of the domain layer just like any other client interface (GUI, command line, etc.)
Apr
24
comment Why is a architecture with anemic models the JavaEE standard?
@RobertHarvey rather you can't move logic between two platforms. Logic is code, not data... unless you're going to write something that converts between one language to the other on the fly. Finally web service contracts are NOT the same thing as domain models. If you're tying those together you're asking for pain.
Apr
24
comment Why is a architecture with anemic models the JavaEE standard?
@YazadKhambata the state is encapsulated in anemic models but not the behavior. when you're talking about two different platforms you're inherently talking about two different applications which are different bounded contexts. You'd connection them probably via web service but the service contracts are just service contracts, they do not have to represent the shape of the domain models the service uses to do its job.
Apr
24
comment Why is a architecture with anemic models the JavaEE standard?
"people go to the anemic domain model antipattern instead in order to not have two objects representing the "same" object.". bingo. The problem is that people are comparing objects by the data they contain instead of the behavior they encapsulate, which imho goes against OO design.
Apr
24
comment Why is a architecture with anemic models the JavaEE standard?
@RobertHarvey You don't in those cases, you end up having to duplicate the code. Anemic models don't even have logic to transfer anyway, they're by definition dumb.
Apr
23
comment Why is a architecture with anemic models the JavaEE standard?
@Oscar it is sad and it seems there are a lot of devs out there that think they're following ddd but aren't.
Apr
23
comment Why is a architecture with anemic models the JavaEE standard?
"Contracts should define the expected structure of inputs, outputs (and exceptions) not the business logic.". interfaces are contracts (and in .net Code Contracts lets you define real DbC contracts which are enforced), not objects. The anemic models you describe effectively revert OO back to procedural programming. Pojos which are designed around being serializable aren't domain objects at all, models should not be anemic, the should be the source of truth for whatever they represent.
Apr
16
comment How do I do SQL Server mapping with a new Desktop application written in C#?
SRP is useful when you are maintaining the class; you're not worrying about maintaining DbContext yourself, someone else is, you should only care that it works. What you claim is your main point appears as a couple of sentences in your entire answer, you just spout out that you believe EF does "too much" and should just avoid it in favor of ORMs which do less.
Apr
16
comment How do I do SQL Server mapping with a new Desktop application written in C#?
Srp applies to a class not a framework. And its a principal mot a hard and fast rule.
Apr
9
comment Should one use Dependency Injection even if the class is used only once?
@AvetisG no, it makes no sense whatsoever, because all those external pieces need to be kept in a state you expect or your tests will start failing, and you won't know if its the code or the state that's broken. They also will be far less detailed (offer less coverage) than good unit tests. I've done plenty of the kinds of tests your talking about, and its far easier to mock than try to keep web services / DBs in their proper state.
Apr
9
comment Should one use Dependency Injection even if the class is used only once?
@AvetisG Seriously? Go google it. Relying on external state for automated tests makes them that much more fragile, prone to false negatives and slower (DB will be much slower than in memory). Acceptance testing means you have people manually trying stuff, which besides the fact that it takes longer also means if you ever find the error, you're much further down the development pipeline than if you had a good unit test and the further away from a local developer workstation it takes to find / fix a bug the more expensive it is.
Apr
9
comment Should one use Dependency Injection even if the class is used only once?
"Unit testing also falls off since I would rather do an integration or acceptance test to see how the method is interacting with the database in a real-life application.". integration or acceptance tests are more costly in terms of maintenance than a unit test, so I'm not sure why those would be your preference. If this is going to be common as you move forward with other classes, the costs of this are going to be very real. Especially if the class representing the legacy code will be rewritten to not be legacy (by further decomposition), you may want to rethink.