On Thu, Jun 12, 2014 at 5:39 AM, wrote:
> When presented with options, these are the possible stances:
>
> 1. (Lead) Become educated on the options and decide on one.
> 2. (Follow) Become educated on the options and remain impartial.
> 3. Remain ignorant of the similarities/differences and decide
> I'm afraid I don't understand what all that means.
>
>
>
> But I invariably go for SQL over any abstraction paradigm.
When presented with options, these are the possible stances:
1. (Lead) Become educated on the options and decide on one.
2. (Follow) Become educated on the options and remai
On Wed, 06 Feb 2013 10:03:08 -0800, rusi wrote:
> On Feb 6, 5:58 pm, Andriy Kornatskyy wrote:
>> The question of persistence implementation arise often. I found
>> repository pattern very valuable due to separation of concerns, mediate
>> between domain model and data source (mock, file, database
I agree that ORMs can be rather complicated; especially when you need
to do some refactoring.
Another reason not to use ORMs is difficult of measuring query complexity.
However, some of the most major advantages of ORMs are:
- Generation of forms
- Same code can be used with multiple backends
- T
On Feb 6, 5:58 pm, Andriy Kornatskyy
wrote:
> The question of persistence implementation arise often. I found repository
> pattern very valuable due to separation of concerns, mediate between domain
> model and data source (mock, file, database, web service, etc).
>
> The database data source is
The question of persistence implementation arise often. I found repository
pattern very valuable due to separation of concerns, mediate between domain
model and data source (mock, file, database, web service, etc).
The database data source is somewhat specific since you can proceed with SQL
fu
