Ув. не очень хочется в даваться в подробности, но стоит задача в написании контролов, которые должны поддерживать Data binding. Проблема в том, что используется Postgres и клиент не хочет закупать PostresDataProvider от CLabs (в нём реализована необходимая фабрика для ADO.NET) В итоге имеется только
npgsql, под который написать фабрику очень и очень проблемотично (таков дизайн npgsql)

Указывать в проперти ConnectionString?
(как тогда выбрать Provider by default?)

Какие ещё будут предложения?

Здравствуйте, Gollum, Вы писали:
G>Здравствуйте, Darkman_CV, Вы писали:
D_C>>Какие ещё будут предложения?
G>А что, к нему через ODBC нельзя приконнектиться разве?

как-то за 5 лет не призодило в голову ODBC заюзать.
А вслучае с ODBC, как контролу находить то, к чему коннектится?

Кажется Вы меня не поняли.
Сам DataProvider имеется (Npgsql), но он без поддержки ADO (ввиду невозможности написать фабрику).
Стандартный класс Connection имеется.

Вопрос состоял в том, как организовать проперти и как выбирать default conn. string, если этот подход оптимален.

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, Darkman_CV, Вы писали:

D_C>>Кажется Вы меня не поняли.
G>Видимо, да

D_C>>Сам DataProvider имеется (Npgsql), но он без поддержки ADO (ввиду невозможности написать фабрику).
G>Вот этого я и не понял. Что вы имеете в виду под "фабрикой" ?

Вот то, что ответил Mike Allen (один из разработчиков) Npgsql (Postgres Data Provider)
==
Currently, Npgsql is not recognised by Visual Studio as an ADO.NET provider.

To implement this, a number of fairly trivial changes need to be made (I guess the developers are already aware of them
— if there's any obstacles I'm not aware of, please let me know). But, IMHO, they would be very worthwhile — not least
because it would then be possible to use the .NET data controls to quickly and easily develop PostgreSQL apps (or to
more easily port to PostgreSQL from SQL Server, for example).

At the root of this change would be an override of the ADO.NET 2.0 System.Data.Common.DbProviderFactory class, which
provides factory methods for creating provider-specific connection, command, etc., objects using a common interface.

For example:

namespace Npgsql {
class NpgsqlFactory : System.Data.Common.DbProviderFactory {

/// <summary>
/// Create a strongly-typed Npgsql connection instance.
/// </summary>

public override System.Data.Common.DbConnection CreateConnection () {
return new NpgsqlConnection ();
}

// etc.
}
}

The only problem is that, for example (there are issues with other Npgsql classes) NpgsqlConnection is derived from
System.ComponentModel.Component and not from System.Data.Common.DbConnection. However, since
System.Data.Connection.DbConnection is itself derived from System.ComponentModel.Component, it should be fairly trival
to modify NpgsqlConnection accordingly. If nothing else, the current interface shouldn't be busted as a consequence.

There's some other bits and pieces required to support provider classes, but they do not appear to be too onerous.

All that then needs to be done is to define the Npgsql provider factory in the <DbProviderFactories> section
of <system.data> in the Machine.config file of the Visual Studio installation.

What do you think about this? I'd be glad to assist with some of the coding if it would help...

Mike
---

А всё остальное у меня имеется.
Вслучае поддержки ADO.NET я бы просто указал DataSource ввиде проперти.

А вот вслучае отсутствия ADO.NET провайдера — в замешательстве.

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, Darkman_CV, Вы писали:

G>Понятно, не полностью поддерживается ADO.NET 2.0.

D_C>>Вслучае поддержки ADO.NET я бы просто указал DataSource ввиде проперти.
D_C>>А вот вслучае отсутствия ADO.NET провайдера — в замешательстве.

G>Не понятно, что мешает? Контрол должен принимать данные из источника — будь то IHierarchicalDataSource, IEnumerable, IList или еще что-то. А уж кто его будет реализовывать — все равно, будь то PostgreDataSource, MsSqlDataSource. Соответственно просто сделать по образу стандартных контролов свойство DataSource и не мучаться.

Дак в том-то и дело, что PostgreDataSource отсутствует, нужно брать базовый и реализовывать сообственный.
Вслучае наличия подобного — вопросов бы не во зникало.

Вопрос состоял в том, что вслучае отсутствия источника, как либо подругому можно реализовать свойство контрола?
(или лучше всё-таки потратить время и написать PostgresDataSource?)

P.S.
Вот от, что пока есть в Npgsql'e

Здравствуйте, Gollum, Вы писали:

G>Здравствуйте, Darkman_CV, Вы писали:

D_C>>Дак в том-то и дело, что PostgreDataSource отсутствует, нужно брать базовый и реализовывать сообственный.
D_C>>Вслучае наличия подобного — вопросов бы не во зникало.
G>А в чем проблема реализовать тот же IList скажем?

D_C>>Вопрос состоял в том, что вслучае отсутствия источника, как либо подругому можно реализовать свойство контрола?
D_C>>(или лучше всё-таки потратить время и написать PostgresDataSource?)
G>Лучше потратить время. Но в чем проблема-то? То, что тут не работают обобщенные типы ADO.NET 2.0 не значит, что нельзя работать в стиле 1.1 — Сonnection, Command, ExecuteReader etc. Или проблема в том, чтобы спроектировать DAL? Но это уже вопрос к контролу не относящийся.

Да, DAL было бы удобнее. С MSSql было бы всё попроще, а тут приходится дописывать всё, чего не хватает.
В стиле ASP.NET 1.1 чёт как-то не очень хочется работать.

Насколько я понял из ваших рекомендаций то нужно: Реализовать PgDataSource?

Здравствуйте, Gollum, Вы писали:
G>Ну давайте возьмем за пример DropDownList. Он унаследован от BaseDataBoundControl, в котором есть свойство DataSource. DataSource принимает следующие интерфейсы: IEnumerable, IListSource, IDataSource, or IHierarchicalDatasource.
G>Соответственно, реализация этих интерфейсов уже зависит от дизайна и конкретики системы. Обычно источник данных — это компонент BL, который использует реализацию некоего контракта из DAL чтобы получить данные. В DAL же будет конкретная реализация для Postgre. Ее придется делать исходя из текущих возможностей.

Т.е. как ни крути, если хочется следовать идеологии ASP.NET 2.0 то DataSource реализовывать прийдётся.

P.S.
Прочитал Ваш последний доклад. Скажите, что действительно всем так интерестна персонализация в виде WebParts?

Прошу прощение за настойчивость в данном вопросе.

А насколько будет, ну, скажем, корретно, если вместо DataSource будет использоватся ConnectionStringName?
Соответственно сам контрол и будет внутри себя делать всё, что ему захочется.

И ещё, вопрос, а как быть с connection poll а данном случае? В ADO.NET имеется, а вслучае использования ConnectionStringName или DataSource?

Огромное Вам спасибо.