О выборе платформы для ВЕБ и ФТП сервера II

← →
kaif © (2008-01-08 01:24) [40]

Ну в принципе можно обратиться к ячейке даже в DataTable.
На C# это выглядит так:

DataTable table = MyDataSet.Tables[0];
DataRow row = table.Rows[0];
string s = row["имя_поля"];

Как видите, в DataTable нет понятия "текущая запись", как в дельфийском TDataSet. Вы обращаетесь с строкам набора как к массиву.

← →
Anatoly Podgoretsky © (2008-01-08 01:32) [41]

> kaif (08.01.2008 01:24:40) [40]

Вот это должно помочь, Сегодня уже не буду проверять, а завтра займусь. Кроме того взгляну в сторону DataView

← →
kaif © (2008-01-08 02:02) [42]

Что касается ObjectDataSource, то я его пока не касалася, предпочитая начать с более простых источников, работающих с серверами баз данных. Сама технология "слоя данных" достаточно сложна. Она предполагает классы бизнес-объектов и их коллекций. ObjectDataSource работает с такого рода объектами и позволяет осуществлять над ними даже что-то вроде SQL-запросов. Почему я считаю эту технологию сложной? Для меня сложно все, что касается сборок и их версий, пока я не набил достаточно руку в этом. А в отношении слоя доступа к данным ведь мы имеем сразу дело со сборкой:
<asp:ObjectDataSource runat="server" ID="MyObjectSource" TypeName="ProAspNet20.DAL.Employees" SelectMethod="LoadAll">

Дино Эспозито на этот счет пишет следующее:

Свойство TypeName возвращает полностью уточненное имя сборки, содержащей вызываемый класс. Если этот класс определен в папке App_Code, имя сборки указывать не нужно. В противном случае задайте строку в форме [имя класса, сборка], разделенную запятой...

Как я понимаю с одной стороны у Вас есть какие-то схемы данных в DataSet, с другой бизнес-классы, и между ними должны быть четкие соответствия (тип и имя колонки таблицы - тип и имя свойства бизнес- класса). Возможно, что-то перестало соответствовать друг другу. Чтобы в этом разобраться, надо сначала хорошо представлять себе, как это все работает (Table Data Gateway) и уметь это все тестировать. То есть сделать руками первый вспомогательный бизнес-класс и класс-коллекцию, присоединить это все к ObjectDataSource и пощупать, как это все работает. А может быть пока обойтись без слоя данных и попробовать для начала поработать с обычными источниками? Там все достаточно просто и понятно... А то так недалеко до разочарования.

← →
Anatoly Podgoretsky © (2008-01-08 11:12) [43]

> kaif (08.01.2008 02:02:42) [42]

Вообще то это очень простая технология, цель кототорй абстрагироваться от данных, путем разделения на три слоя - слой данных (DAL), слой бизнес логики (BLL) и слой презентации (страницы). Реализуется очень просто. Опишу на словах

В папке App_Code создаются две папки DAL и BLL
В папку DAL помещается схема данных.
В папку BLL помещаются бизнес правила, которые в общем случае являются простым враппером над запросами из DAL.
На странице вместо прямого вызова запросов используются вызовы функций из BLL.
Реализация простая, вот самый простой пример.

Imports SiteTableAdapters <System.ComponentModel.DataObject()> _ Public Class TablesBLL Private _TablesAdapter As TablesTableAdapter = Nothing Protected ReadOnly Property TablesAdapter() As TablesTableAdapter Get If _TablesAdapter Is Nothing Then _TablesAdapter = New TablesTableAdapter() End If Return _TablesAdapter End Get End Property <System.ComponentModel.DataObjectMethodAttribute(System.ComponentModel.DataObjec tMethodType.Select, True)> _ Public Function TablesGetData() As Site.TablesDataTable Return TablesAdapter.GetData() End Function End Class

Если не делать BLL, то динамический вызов методов из DAL становится не удобным, менее удобным, чем без использования DAL, поскольку привязать колонки в дизайнтайм будет не возможно и управлять ими тоже. С BLL я могу настроить все колонки в дизайн тайм, также как и без DAL но уже абстрагируясь от методов доступа к данным.

Я постепенно прошел все три метода и могу сказать, что три слоя действительно мне дают свободу и гибкость, а также очень удобны в работе. Ну и идеологически правильно отделять представляения от данных, а данные от бизнес правил. Тот пример что я привел это очень простой пример, минимальный уровень бизнес правил.

Ну вот я закончил перевод проекта на ASP.NET теперь можно говорить и о стабильности среды.

1. Иногда начинает дурить после длительной работе, не узнает переменные и объекты, но это не критично - лечится перезапуском

2. Серьезное - это разрушение проекта при изменении в DAL, если запрос не соответствует схеме, то при перестройке схемы портит безнадежно проект, лечится с трудом, точного решения не знаю, но можно быть просто внимательным или делать отдельную схему для таких запросов. Это ошибка среды, исправят наверно в будущем. Бекап не помогает, сам проект не портится, а портится схема и ее временные объекты.

3. В среде потеряно абсолютное позиционирование, отсутствует пункт Layout и все с ним связаное, также многие инструменты не работают, возможно из-за того, что версия Express

Резюме - работать вполне можно, стабильность и справка лучше чем в Д2006, хотя явно, что Борландовская среда сделана на основе технологии Микрософта, обмен патентами и технологиями, но Борланд не владеет внутренней информации или не умеет работать с технологией.
Справка же - просто пофигизм со стороны Борланда.

Забыл добавить, у меня проект сложный, свыше 3.5 гб и порядка 200 aspx модулей. Это наверно вносит свой вклад.

Проект отлажен, всего три ворнинга (не может найти три файла по ссылке, но это ошибка среды, поскольку это папки, а не файлы). На работоспособность это не влияет.

Для того что бы программировать, надо знать много технологий, для непрофессионала тяжело.

О выборе платформы для ВЕБ и ФТП сервера II Найти похожие ветки