Презентация, бизнес и слой данных
Вы можете объединить таблицы, используя union all. В MySQL 8+ вы можете рассчитать последний столбец, используя кумулятивные суммы:
select id, date, debit, credit,
sum( coalesce(debit, 0) - coalesce(credit, 0) ) over (order by date) as balance
from ((select id, date, debit, null as credit
from debit
) union all
(select id, date, null as debit, credit
from credit
)
) b
order by date;
В более ранних версиях вы можете использовать переменные для расчета:
select b.*,
(@b := @b + coalesce(debit, 0) - coalesce(credit, 0)) as balance
from (select id, date, debit, credit
from ((select id, date, debit, null as credit
from debit
) union all
(select id, date, null as debit, credit
from credit
)
) b
order by date
) b cross join
(select @b := 0) params
order by date;
5 ответов
Jon,
One of the first things to understand is that if you intend to build layer-based applications, then you should not be storing SQL statements directly within ASPX pages (as the SqlDataSource requires). The SqlDataSource control was built to demonstrate how easy it is to bind and update an application with database data and is not intended to be used in real world applications, because it kinda defeats the purpose of having a BL layer and Datalayer if you are going to store Select/Update/Delete/Insert statements in the ASPX page.
The whole purpose of layer-based application design is to encapsulate each layer so that there is no intersection. Each layer interacts with the public interface of the other layers and knows nothing about their internal implementation.
The viable alternative, therefore, is to use the ObjectDataSource control. This control allows you to bind directly to a DataLayer or to a Biz logic layer which in turn can call the Datalayer. Binding to a Datalayer directly has the drawback that you will be returning data structures which expose the schema of the database tables (for e.g., DataTables or DataViews).
So, the recommended flow of logic is as follows:
The ASPX page uses a DataSource control to bind to a BL class.
This BL class provides appropriate functions such as GetData, UpdateData, DeleteData and InsertData (with any required overloads) and these functions return strongly typed objects or collections that the ObjectDataSource can work with and display.
Each public function in the BL class internally calls into the DataLayer to select/update/delete/insert data to/from the database.
An excellent introduction to this layer based design in ASP.NET is provided in the Quickstarts
P.S: @Andy mentioned generic datalayers that work with all scenarios. See this question for an example of what it would look like.
Вся идея создания слоя приложения заключается в том, что каждый уровень не зависит от деталей реализации нижеследующего (ых) уровня (ов). Например, в вашем коде у вас есть оператор T-SQL внутри уровня представления. Это означает, что у вас есть прямая зависимость вашего уровня представления от вашей базы данных (нижний уровень). Если вы вносите изменения в свою базу данных, вы также должны внести изменения в свой уровень представления. В идеале это не то, что вы хотите. Уровень представления должен заботиться только о представлении данных, а не о том, как их получить. Предположим, вы переместили всю свою базу данных в файлы CSV (я знаю, безумная идея), тогда ваш уровень представления вообще не должен знать об этом.
Так что в идеале у вас есть метод бизнес-уровня, который возвращает только те данные, которые вы хотите показать пользователю. Вам следует взглянуть на ObjectDataSource вместо SqlDataSource . SqlDataSource хорош для небольших проектов по созданию прототипов, но вы не должны использовать его для более серьезных проектов.
Между бизнес-уровнем и уровнем данных у вас должно быть подобное разделение. Уровень данных отвечает за получение нужных данных из некоторого места хранения (базы данных, файла CSV, веб-службы и т. Д.). Опять же, в идеале, бизнес-уровень не должен зависеть от деталей реализации уровня данных. Если вы говорите, например, с SQL Server, вы не должны возвращать экземпляр SqlDataReader на свой бизнес-уровень. Делая это, вы создаете зависимость вашего бизнес-уровня от деталей реализации вашего уровня данных: фактической базы данных, из которой он получает свои данные.
На практике вы видите, что бизнес-уровень действительно так или иначе зависит от деталей реализации уровня данных, и обычно это неплохо. Когда вы в последний раз решили переключать базы данных? Но устранение зависимостей и максимально возможная изоляция деталей реализации почти всегда приводят к тому, что приложение легче поддерживать и понимать.
Подобное объяснение можно найти здесь здесь .
Наибольшее объяснение логических уровней в приложениях ASP.NET происходит из двух источников. Первый - это собственный веб-сайт Microsoft ASP.NET, написанный Скоттом Митчеллом, который представляет собой хорошее введение в разделение логики. Уроки довольно многословны, но я нашел их очень полезными. URL-адрес http://www.asp.net/learn/data-access/ .
Второй ресурс, который я нашел очень полезным, был написан Imar Spaanjaars и доступен для скачивания. здесь . Это гораздо более техническая статья, но она предоставляет отличный способ добавить структуру в ваше приложение.
Надеюсь, это поможет.
Ян.
Если вы напишите свой код, чтобы он был в конечном итоге переносимым, вы обнаружите, что в вашем приложении будет 3 (или более!) Уровня.
Например - вместо создания уровня доступа к данным работайте специально для этого приложения, запишите его, чтобы вам никогда не пришлось писать его снова. Убедитесь, что все ваши функции могут быть переданы переменные, и вы не полагаетесь на глобальные переменные (или как можно меньше). Когда придет время для вашего следующего проекта - скопируйте и вставьте свой DAL, и вдруг вы снова запустите его.
И это не заканчивается - вы можете написать подслой для вашего DAL, который интерпретирует между MySQL и MSSQL (просто в качестве примера). Или у вас может быть библиотека общих функций, которые вы выполняете, таких как санация текста или генерация CSS или что-то в этом роде.
Если вы напишите свой код так, чтобы однажды, вы садитесь, чтобы написать приложение - и это в основном включает в себя вырезание и вставку предыдущего кода - вы достигли нирваны программиста. :)
Помимо основной темы его вопроса, я бы порекомендовал вам взглянуть на ASPNET_REGSQL, чтобы настроить вашу базу данных SQL для обработки встроенных возможностей членства / профиля / роли .Net. Это избавит вас от лишних хлопот и проблем с созданием / обновлением пользователей и т. Д. Я не очень много использовал профиль, но он позволяет вам «прикрепить» дополнительные атрибуты к вашему пользователю, например, AccessCode.
Если вы имеете дело с существующей структурой БД, которая уже выполняет аутентификацию пользователя и т. д., вы можете создать настраиваемого поставщика членства, который будет использовать существующие таблицы БД и хранимые процедуры.