Если вы не можете включить всю таблицу SQL в свой внешний список, тогда вы не сможете запрашивать этот набор данных, как список SharePoint.
Тем не менее, я могу предложить решение, которое мы использовали для сценариев, практически идентичных этому, и которое сработало для нас очень хорошо. В нашем сценарии мы запрашиваем базу данных Oracle, и для возврата больших наборов данных требуется вечность.
Подход, который мы выбрали, заключался в использовании шаблона Factory, чтобы определить, какими средствами следует запрашивать источник данных (список SharePoint, внешнюю базу данных и т. Д.).
Приведенные ниже примеры несколько банальны, но они хорошо иллюстрируют концепцию.
Итак, начнем с интерфейса, который определяет, как будет запрашиваться набор данных и какие поля будут возвращены:
public interface IQueryData
{
string ListToQuery { get; set; }
List<MyResultObject> ExecuteQuery();
}
У вас был бы настраиваемый объект, представляющий одну запись, возвращаемую запросом.
public class MyResultObject
{
public string FileRef { get; }
public string Title { get; set; }
// any other fields you'd like to see potentially returned...
}
Тогда у вас будет поставщик данных, который реализует этот интерфейс для источника данных SQL.
public class SqlDataProvider : IQueryData
{
public string ListToQuery { get { return "BigSqlTable"; } }
public List<MyResultObject> ExecuteQuery()
{
// query your external data source here...
// populate a list of MyResultObject's from the result set and return it to the consumer
}
}
У вас также будет поставщик данных, который реализует интерфейс для источника данных SharePoint.
public class SharePointDataProvider : IQueryData
{
public string ListToQuery { get { return "MySharePointList"; } }
public List<MyResultObject> ExecuteQuery()
{
// query your SharePoint list here, using CAML, SharePoint object model, etc...
// populate a list of MyResultObject's from the result set and return it to the consumer
}
}
С помощью этой реализации вы инкапсулировали логику и детали запроса в соответствующих поставщиках данных.
Теперь у вас будет Factory, который создает соответствующий поставщик данных (на основе указанного параметра ListToQuery):
public static class QueryDataProviderFactory
{
public static IQueryData Build(string listToQuery)
{
switch(listToQuery)
{
case "BigSqlTable": return new SqlDataProvider(); break;
case "MySharePointList": return new SharePointDataProvider(); break;
// you can have many other implementations here that query your data sources in different manners
}
}
}
Наконец, вы должны использовать свою фабрику, чтобы инициировать запрос, передавая имя источника данных, который вы хотите запросить:
public List<MyResultObject> RunQuery()
{
return QueryDataProviderFactory.Build("BigSqlTable").ExecuteQuery();
}
Этот шаблон сохраняет вашу внешнюю реализацию инкапсулированной в ее собственный поставщик данных и абстрагирует детали запроса от потребителя. Все, что нужно сделать потребителю, - это указать имя списка, который он хочет запросить, и Factory решает, какую реализацию инициировать.
Вы даже можете заставить свой интерфейс IQueryData реализовывать универсальные шаблоны для дальнейшей расширяемости:
public interface IQueryData<T>
{
string ListToQuery { get; set; }
List<T> ExecuteQuery();
}
Это откроет дверь для потребителя, чтобы также указать тип объекта, который они ожидают вернуть.
В нашем интерфейсе данных запроса на самом деле гораздо больше членов, которые добавляют еще больше точек расширяемости нашим поставщикам запросов, но я подумал, что этот пример иллюстрирует эту точку в краткой и простой для понимания манере.
Просто хотел предложить это предложение, поскольку похоже, что это практически тот же сценарий, с которым мы столкнулись год или около того назад, и эта стратегия очень хорошо работает для нас.
person
KodeKreachor
schedule
08.04.2012
