just some:
3: in the medium term, I hope to find time to move dblinq to a better
service location infrastructure.
(actually i'm thinking about the Common Service Locator)
I agree that some interfaces could be removed, but some should not (as
IQueryCache for example). We should only remove those interfaces that are
too much coupled with their user and/or their implementer that there's no
sane reason to reimplement in an alternative way.
(an example could be IDataMapper as far as I remember).
But such interfaces often are index of a deep refactoring needed (as the
IDataMapper for example).
I don't agree that interfaces complicate mantainence. When correcly designed
they have a single abstract responsibility, making mantainence far easier,
and allow to parallelize the programmers' work.
So interfaces should be used each time that we could imagine a different
implementation with the same shape: adding a method could add a behaviour
not change an existing one.
BTW when no other behaviour are possible (becouse of the coupling) we could
remove interface (but adding a TODO: evaluate refactoring needs here)
Giacomo
On Thu, May 7, 2009 at 9:42 PM, Jonathan Pryor <[email protected]> wrote:
> I'd like to start a discussion about "cleaning up" the DbLinq source
> tree. I have two annoyances I'd like to clean up.
>
> First #if removal. I understand (and support) the need for #ifs
> (especially since they're needed for Mono). I don't think we need to use
> #if as often as we do, though. Consider this, from
> src/DbLinq/Data/Linq/Sugar/Implementation/QueryCache.cs:
>
> #if MONO_STRICT
> namespace System.Data.Linq.Sugar.Implementation
> #else
> namespace DbLinq.Data.Linq.Sugar.Implementation
> #endif
> {
> internal class QueryCache : IQueryCache
>
> The class is internal, and thus will never be exported from the
> assembly. Other assemblies are public, but only for the !MONO_STRICTbuild.
>
> Consequently, I would like to remove most of these, and just stick to the
> DbLinq root namespace.
>
> Secondly, and more likely controversially, I'd like to remove most of the
> interfaces (e.g. ISqlProvider, etc.), for several reasons:
>
> 1. FxDG suggests using classes over interfaces most of the time, because of
> easier versioning. You can easily add methods to classes without "breaking"
> existing derived types, but it's not possible to add new methods to
> interfaces. (See also the earlier email for fixing .Count() SQL
> generation.) For comparison, consider how .NET 1.0 had the IDb*interfaces,
> while .NET 2.0 moved to the
> Db* classes. Easier versioning is useful.
>
> 2. Most derived types are already using the helper classes instead of the
> interfaces.
>
> 3. The interfaces *complicate* maintenance. If use VS.NET and you're in a
> method, e.g. QueryBuilder.BuildSqlQuery(), and you right-click
> SqlBuilder.BuildSelect(), right-click, and click *G*o To Definition, you
> wind up at the interface definition. That's not very useful. Especially
> since we use ObjectFactory.Get<T>(), so there can really only be one
> implementation for the ISqlBuilder interface *anyway*. The "workaround"
> is to use Find All References, which is slower and cumbersome compared to Go
> To Definition. This is clunky.
>
> 3.a. Another place where maintenance is complicated is in the necessary
> duplication of methods between the interface and the implemented types.
> When this is needed, it's a necessary complication, but I don't see the need
> for it. The result is that if you need to add behavior that requires
> changing an interface, you change the interface and all implementations
> (even when -- *especially when* -- there's a sane default behavior for the
> added method).
>
> 4. The use of interfaces leads to having nested Implementation directories
> everywhere, which makes for "deeper" project solutions and longer namespace
> names (and thus harder to navigate to files within the VS Solution
> Explorer). I would like to remove them, thus "flattening" the project
> directory structure.
>
> Thoughts?
>
> - Jon
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---
