Быстрый способ вернуть список настраиваемых объектов из метода страницы без отдельного BLL

Я использую jQuery для получения объекта JSON из метода страницы. У меня есть DAL, который использует SubSonic, и если я верну объекты, созданные из классов, сгенерированных SubSonic, я забью трубы. :) Вы знаете, все публичные свойства сериализуются. Мне не нужен отдельный бизнес-уровень для этого приложения, потому что он небольшой и ориентирован на операции чтения, а еще один уровень кажется излишним. Чтобы избежать загрузки некоторых раздутых объектов SubSonic (возможно, также с конфиденциальной информацией) и избежать создания отдельного слоя, я попытался вернуть список объектов, например:

[WebMethod]
public static List<object> GetFiles()
{
    FileCollection collection = DB
        .Select()
        .From(DataAccess.File.Schema)
        .ExecuteAsCollection<FileCollection>();

    List<object> files = new List<object>(collection.Count);

    foreach (DataAccess.File file in collection)
    {
        files.Add(new {
                          file.FileId,
                          file.ApplicantFirstName,
                          file.ApplicantLastName,
                          file.UploadDate
                      }
        );
    }

    return files;
}

Это работает, и я получаю взамен хороший объект JSON (не обращая внимания на значение DateTime):

[{"FileId":1,"ApplicantFirstName":"Paweł","ApplicantLastName":"Krakowiak","UploadDate":"\/Date(1235656448387
)\/"}]

Это хороший подход? Меня беспокоит List<object> - это хуже, чем возвращение, скажем, List<SomeDomainObject>? Представление? Что-то другое?

Это .NET 2.0, я не могу использовать возможности 3.5. По крайней мере, анонимные типы работают ...


json c# .net-2.0 subsonic
person Pawel Krakowiak    schedule 26.02.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Самая большая рекомендация может заключаться в том, чтобы сделать его «Коллекцией», а не списком, но с простым возвратом веб-службы это не так уж важно, поскольку эта рекомендация чаще всего встречается в средах, где объект все еще находится в. NET сборки.

Думаю, это тоже легко читать.

person Mitchel Sellers    schedule 26.02.2009

arrow_upward
1
arrow_downward

Единственным недостатком использования List<object> вместо List<SomeDomainObject> в этом сценарии будет потеря строго типизированного доступа при вызове вашего метода GetFiles непосредственно из кода .net.

person Ken Browning    schedule 26.02.2009
comment
Спасибо. Мне не нужно где-либо использовать этот метод в .NET, его единственная цель - вернуть некоторые данные клиенту, поэтому похоже, что List ‹object› будет в порядке. - person Pawel Krakowiak; 27.02.2009

arrow_upward
0
arrow_downward

Похоже, в моем подходе нет ничего плохого. Все, что я хочу сделать, это вернуть объект JSON вызывающему клиенту (браузеру) для обновления пользовательского интерфейса. Это приложение выполняет 99% операций чтения, так что меня это устраивает. Я фактически начал добавлять слои Services и Domain (я держу здесь свои бизнес-сущности), но я собираюсь их выбросить. Я действительно стараюсь, чтобы это приложение было простым, и не добавляю ненужных вещей.

person Pawel Krakowiak    schedule 27.02.2009