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_STRICT
build.
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 Go 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
-~----------~----~----~----~------~----~------~--~---
