Reputation
1,470
Top tag
Next privilege 2,000 Rep.
Edit questions and answers
Badges
6 14
Newest
 Yearling
Impact
~39k people reached

  • 0 posts edited
  • 0 helpful flags
  • 15 votes cast
Aug
8
comment Keeping an MVC model loosely coupled from the DB?
@Industrial: Keep in mind also that the repository methods don't have to just be CRUD. Lots of intelligence can be baked into that code. A lot of the more complex ones can have a lot of internal code which transforms data from the database. Or, if the complex ones involve many trips to the database, then for performance gains you can put the logic in a stored procedure and the DAL method just passes through to that procedure and translates the results into models.
Aug
8
comment Keeping an MVC model loosely coupled from the DB?
@Industrial: For example, if you use an ORM, then that ORM would be referenced by your DAL (which is isolated from the domain models) and would transform your models into data access accordingly. Or if you do direct database access with manual SQL, you'd do that in your DAL's repository methods and translate the results of the SQL queries into domain models before returning them.
Aug
8
comment Keeping an MVC model loosely coupled from the DB?
@Industrial: There are a number of ways to connect models to persistence, but so far the only method I've found which truly satisfies my desire to separate concerns is to have repository interfaces in the domain which are externally implemented by a DAL. The repository methods accept and return domain models, and internally converts between those and any generated database entities. (To be honest, I haven't done this much in PHP.) So you can use a DAL framework to auto-generate all your DB CRUD, etc. and then write your repositories as an interface between that stuff and your models.
Aug
8
answered Keeping an MVC model loosely coupled from the DB?
Aug
7
comment When do you start documenting the code?
@Graham Lee: True. But many times a meaningful name isn't enough. A short paragraph can be warranted to explain why something is happening a specific way. The code may very well express what it's doing, the names may very well express all the players, but if the deeper meaning isn't captured then a comment is most definitely warranted.
Aug
7
answered When do you start documenting the code?
Jul
19
awarded  Supporter
Jun
24
awarded  Commentator
Jun
24
comment Is there an agile project management technique for developing innovative software systems?
"The development is innovative since we don't know how to develop it" - Best definition of "innovative" I've ever heard. Our marketing department is going to love that one.
Apr
15
awarded  Nice Answer
Apr
15
awarded  Editor
Apr
5
awarded  Mortarboard
Mar
15
comment Advice: How to convince my newly annointed team lead against writing the code base from scratch
@Mark Canlas: Absolutely. And that's where a lot of developers (even very experienced ones in many cases) lose their grip on the overall business. It has to have actual tangible value for the business, and very often the existing product has that value. Though one argument I always hate from the business is "we already spent money on this, so we need to use this." Sometimes, as in the case of my last job, a decision like that drives them into the ground. It's neither "always re-write" nor "never re-write." As you said... balance.
Mar
15
comment Advice: How to convince my newly annointed team lead against writing the code base from scratch
@Mark Canlas: It's kind of funny actually, because I'm often a proponent of re-writing. I hate legacy code :) But I also understand that if I can't demonstrate added value to the business, the re-write shouldn't happen. My opinion needs to be backed by numbers.
Mar
15
answered Advice: How to convince my newly annointed team lead against writing the code base from scratch
Mar
14
awarded  Nice Answer
Mar
14
answered Does SCRUM usually involve massive overtime?
Feb
18
awarded  Good Answer
Feb
18
awarded  Nice Answer
Feb
18
comment When should I use—and not use—design patterns?
@user374980: Agreed. The patterns themselves are essentially language-agnostic, but different languages will have different details on the best way to implement them. Simply porting an implementation from C# to, say, Ruby may be ill-advised. Attempting the same to Lisp is downright silly :)