Suggestions wanted for better organization of the project

[Noah]

Currently the source lives in C#-SQLite, should that be renamed to:
* Community.Data.SQLite
* Community.Data.SQLiteServer
* Community.Data.SQLite.Windows

All the interesting code lives in the namespace Community.Data.SQLite
and the public class csSQLite

Which means to access the public api, we write code like the
following:

using Community.Data.SQLite;
...
return csSQLite.sqlite3_libversion();
...

Is there a better public class name?

Other suggestions are welcome.

Noah

[Kevin Gadd]

I suggest renaming the class to sqlite3 and removing the 'sqlite3_'
prefix from all the APIs. It would require some project-wide renames
but I think would make the library much friendlier to C# programmers
without significantly changing any syntax (sqlite3_foo becomes
sqlite3.foo, if you've done the proper 'using').

I think Community.Data.SQLite.Managed is an appropriate name, to
distinguish it from other implementations of Community.Data.SQLite
(like the one that talks to the native library).

-kg

[Kosenko Max]

Current approach seems fine to me.
I'd recommend to stay away from Windows or Server names since it's not
a server and mainly useful in Silverlight and Mono projects and not
Windows.

[Miguel de Icaza]

Hello Noah,

return csSQLite.sqlite3_libversion();
...

Is there a better public class name?

The csSQLite name does not blend very well with .NET, I suggest that the name of the class follows the standard naming pattern, some options:

CsSqlite, CSharpSqlite, SharpSqlite, SqliteCs, ManagedSqlite, CliSqlite.

I personally would not nest things inside "Community.Data", it feels as if there is a bigger picture that one day will be completed.

I would just call it "Community.SqliteXXXX", and let data go, I do not think there will ever be any confusion what Sqlite is about.

Miguel

[Daniel Morgan]

Just my 2 cents...

I would not rename sqlite3_xxx() functions because you need a way to
map to the original sqlite c library. When a new version comes out of
the sqlite c library, can you easily incorporate those changes in your
C# version?

Otherwise, if you do rename the functions, then I would create a text
document which map the friendly C# functions to the C functions.

Personally, I think there should be at least 2 wrapper APIs of csharp-
sqlite.
1. a non-ADO.NET wrapper that does not depend on System.Data. Make
this API easy to use.
Maybe, it could even work like the ADO.NET wrapper.
2. an ADO.NET wrapper that depends on System.Data

[Noah Hart]

After review of all the suggestions, my preferred
changes are as follows:

1) Change source code tree to Community.Data.CSharpSqlite
2) Change namespace to Community.Data.CSharpSqlite
3) Change class name from csSQLite to SQLite3
4) add alias functions for all the sqlite3_api functions to allow
SQLite3.api type calls

I don't really like the Data. part of the namespace, but don't really
see any harm in leaving it in place.

As always, your feedback is welcome

Noah

[Miguel de Icaza]

Hello Noah,

1) Change source code tree to Community.Data.CSharpSqlite
2) Change namespace to Community.Data.CSharpSqlite
3) Change class name from csSQLite to SQLite3
4) add alias functions for all the sqlite3_api functions to allow SQLite3.api type calls

I don't really like the Data. part of the namespace, but don't really see any harm in leaving it in place.

My only feedback is that the Framework Design Guidelines explicitly advise against capitalizing acronyms like that:

http://msdn.microsoft.com/en-us/library/ms229043.aspx

The convention is to not capitalize SQL, so in this case it would be Sqlite3

[Kosenko Max]

Hello.

I think that API should be exactly the same as in native version.
Otherwise you can't use native SQLite docs.

Namespace looks better as Community.CsharpSqlite because it has NO
correlation to System.Data namespace at all and it follows guidelines
on namespace namings.

IMHO ADO.NET wrapper should really be based on System.Data.Sqlite code
from http://sqlite.phxsoftware.com/. It's not hard to add support
there and it's mature enough. Btw - it's also good idea to help Robert
in updating and improving ADO.NET wrapper instead of doing own one.

Max.

[Kosenko Max]

Well, it looks like Robert already doing support for csharp-sqlite and
promises it till the end of this month.
http://sqlite.phxsoftware.com/forums/p/2109/8975.aspx#8975

On 18 фев, 14:53, Kosenko Max <kosenko....@gmail.com> wrote:
> IMHO ADO.NET wrapper should really be based on System.Data.Sqlite code

> fromhttp://sqlite.phxsoftware.com/. It's not hard to add support