Prev: UML Activity Diagram - 1 Activity across 2 or more swimlanes
Next: "OOP is Dead" article
From: Frans Bouma on 5 Feb 2007 03:57
Mikeon wrote:

> > See it like this: you have in your repository an object
> > which generates SQL based on specifications you pass into the
> > repository. How that's done isn't important to the repository.
> > WHICH object is used by the repository is also not defined inside
> > the repository, but set outside the repository, for example by
> > passing in the sql generator object on the constructor of the
> > repository.
>
> Ok, I know what IoC means. What I don't know is how to convert
> Specification to Query Objects automatically.

Nothing is automatic. First you have design, then you implement that
design. 'specification' and 'query object' is something you have to
come up with.

Reading your posts lately, I have the feeling that you have read about
some elements 'how to do it right' and are now asking how to write the
code for these elements, while actually that should be trivial. So
instead of searching for clues what all the DDD elements are and how
they are supposed to be working together in theory, why not take a step
back, think for a second or 2 and come up with the solution yourself?

If you have specifications on one side and you need to make SQL out of
it, you thus need to interpret the specifications in such a way that
the SQL engine you have can spit out sql. Or whatever that has to be
emitted.

The SQL engine likely has a fixed interface, and your specifications
also have a set of rules to obey, I'm sure. It then should be
tic-tac-toe to get from specifications to SQL via the sql interface.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
From: Mikeon on 5 Feb 2007 04:28
> Reading your posts lately, I have the feeling that you have read about
> some elements 'how to do it right' and are now asking how to write the
> code for these elements, while actually that should be trivial.

Yes I'm trying to do things "right" whatever that means ;-)
And no it is not trivial. Everybody writes how beautiful specification
pattern and repositories are, but noone knows how to make use of them.

> The SQL engine likely has a fixed interface, and your specifications
> also have a set of rules to obey, I'm sure. It then should be
> tic-tac-toe to get from specifications to SQL via the sql interface.

no it's not.

Assume for a moment that I'm not specially smart (which may be true
even without assumptions).
How do you expect me to translate:

bool IsSatisfiedBy(User usr)
{
usr.Password == "pass";
}

to
new Query("Password", "pass");
or even to
SELECT ... WHERE Password = "pass"

other than to write those lines in the specification pattern itself?

I'm serious. I have no idea how to do it and writing the same code
twice: once for IsSatisfiedBy and once to get the Query or SQL is just
something I have problems accepting because it makes specification
pattern way less usefull than I thought.

--
Michal

From: Mikeon on 5 Feb 2007 04:37
> new Query("Password", "pass");
> or even to
> SELECT ... WHERE Password = "pass"
>
> other than to write those lines in the specification pattern itself?


OH! there is also another solution that I can think of. For each
persistance system that I would like to use, create some kind of
translator object that can take a specification and spit SQL for
example. But this translator has no way to analyze the code of the
specification other than a very low level IL/ByteCode analysis.
I'm aware that in .NET there are new features comming: expression
trees in particular, that will solve my problem: i.e.: I know how to
write SQL given expression tree.
But my question is generic and not .NET 3.5 specific.

From: Frans Bouma on 6 Feb 2007 04:00
Mikeon wrote:

> > Reading your posts lately, I have the feeling that you have
> > read about some elements 'how to do it right' and are now asking
> > how to write the code for these elements, while actually that
> > should be trivial.
>
> Yes I'm trying to do things "right" whatever that means ;-)
> And no it is not trivial. Everybody writes how beautiful specification
> pattern and repositories are, but noone knows how to make use of them.

Software engineering isn't about 'apply this pattern' or 'apply that
pattern', it's about solving problems. The thing you have to do is
solve a problem, not apply a pattern or two. If you don't understand
the pattern, don't apply it, it's as simple as that. You then go back
to your original problem and think of another solution.

Likely you'll come up with something which resembles the pattern you
wanted to implement in the first place. You see, patterns are
'recognized ways people solve the same problem over and over again',
though the KEY here is 'the same problem'. First determine that you
have to solve that same problem and then look into a way to solve it.

Just using repositories and a specification pattern (whatever that is)
doesn't make your software all of a sudden good and solid: if you don't
know what you're using/applying, you'll end up with a mess. So apply
what you THINK should be applied, namely a solution you UNDERSTAND and
which you think will solve your problem.

> > The SQL engine likely has a fixed interface, and your
> > specifications also have a set of rules to obey, I'm sure. It then
> > should be tic-tac-toe to get from specifications to SQL via the sql
> > interface.
>
> no it's not.
>
> Assume for a moment that I'm not specially smart (which may be true
> even without assumptions).
> How do you expect me to translate:
>
> bool IsSatisfiedBy(User usr)
> {
> usr.Password == "pass";
> }
>
> to
> new Query("Password", "pass");
> or even to
> SELECT ... WHERE Password = "pass"
>
> other than to write those lines in the specification pattern itself?

What's 'the specification pattern'? I now write professional software
for over 13 years, but I never heard of the specification patten until
this thread.

But let's see what you posted.

You post a method 'IsSatisfiedBy' which sets a property. What is
IsSatisfiedBy supposed to do?

And more importantly: what are YOU trying to solve? because that's
unclear to me. All you're doing is creating all kinds of abstractions
while there's IMHO no real need for them.

> I'm serious. I have no idea how to do it and writing the same code
> twice: once for IsSatisfiedBy and once to get the Query or SQL is just
> something I have problems accepting because it makes specification
> pattern way less usefull than I thought.

As long as you keep thinking that patterns are building blocks, you
won't solve this.

Patterns are known ways to solve a very specific problem, namely the
problem the pattern solves, and NO OTHER PROBLEM. This means that
UNLESS you have to solve that same problem, you SHOULDN'T apply the
pattern.

To generate SQL, you need meta-data and object data. Meta data is
needed to translate from object element to db element(s) and the object
data is needed to create predicates and expressions in your SQL query.

The meta-data is static, it's the mapping information provided to the
o/r mapper. The object data is the data you provide through the objects
used in your system.

You then need to specify in the language of the o/r mapper used which
query to generate. YES you have to do that SOMEWHERE. If you're looking
for a way to NOT specifying that SOMEWHERE, you won't solve this,
simply because you have to specify somewhere that you want to consume
at spot S a set of entities matching a given filter for example.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
From: Frans Bouma on 6 Feb 2007 04:02
Mikeon wrote:

> > new Query("Password", "pass");
> > or even to
> > SELECT ... WHERE Password = "pass"
> >
> > other than to write those lines in the specification pattern itself?
>
> OH! there is also another solution that I can think of. For each
> persistance system that I would like to use, create some kind of
> translator object that can take a specification and spit SQL for
> example. But this translator has no way to analyze the code of the
> specification other than a very low level IL/ByteCode analysis.

Why would you want to use this, an o/r mapper has this build in
already, so just write the code in a repository if you want to and swap
repositories IF you ever want to swap o/r mappers.

Frankly, not a lot of people swap o/r mappers. Like there aren't many
people writing their code in such a way that they can swap out a
complete UI widget library on the spot, because 'you'll never know!'...

> I'm aware that in .NET there are new features comming: expression
> trees in particular, that will solve my problem: i.e.: I know how to
> write SQL given expression tree.

No, that won't solve your problem, because parsing that expression
tree is very complicated and unnecessary.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: UML Activity Diagram - 1 Activity across 2 or more swimlanes
Next: "OOP is Dead" article