Простота: убедитесь, что у вас надежные слои доступа к данным и бизнес-логике. Вы должны избегать соблазна напрямую обращаться к базе данных с вашего кода ASPX!
Даже с надежной схемой базы данных, теперь я делаю так, чтобы практика никогда не работала с SQL в кодах - практика, которая развивалась только после того, как она усвоила, что у нее есть свои недостатки.
Вот несколько советов, чтобы помочь процессу:
Во-первых, исследовать класс ObjectDataSource. Это позволит вам создать надежный BLL, который все еще может управлять элементами управления, такими как GridView, без использования прямого SQL. Они выглядят так:
<asp:ObjectDataSource ID="ObjectDataSource1" runat="server"
OldValuesParameterFormatString="original_{0}"
SelectMethod="GetArticles" <-- The name of the method in your BLL class
OnObjectCreating="OnObjectCreating" <-- Needed to provide an instance whose constructor takes arguments (see below)
TypeName="MotivationBusinessModel.ContentPagesLogic"> <-- The BLL Class
<SelectParameters>
<asp:SessionParameter DefaultValue="News" Name="category" <-- Pass parameters to the method
SessionField="CurPageCategory" Type="String" />
</SelectParameters>
</asp:ObjectDataSource>
Если построение экземпляра класса BLL необходимо передать аргументы, вам нужна ссылка OnObjectCreating. В вашем коде, реализовать это как так:
public void OnObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
e.ObjectInstance = new ContentPagesLogic(sessionObj);
}
Далее реализации BLL требует еще несколько вещей, которые я спасу вас от Googling. Вот реализация, которая соответствует вышеперечисленным вызовам.
namespace MotivationBusinessModel <-- My business model namespace
{
public class ContentPagesItem <-- The class that "stands in" for a table/query - a List of these is returned after I pull the corresponding records from the db
{
public int UID { get; set; }
public string Title { get; set; } <-- My DAL requires properties but they're a good idea anyway
....etc...
}
[DataObject] <-- Needed to makes this class pop up when you are looking up a data source from a GridView, etc.
public class ContentPagesLogic : BusinessLogic
{
public ContentPagesLogic(SessionClass inSessionObj) : base(inSessionObj)
{
}
[DataObjectMethodAttribute(DataObjectMethodType.Select, true)] <-- Needed to make this *function* pop up as a data source
public List<ContentPagesItem> GetArticles(string category) <-- Note the use of a generic list - which is iEnumerable
{
using (BSDIQuery qry = new BSDIQuery()) <-- My DAL - just for perspective
{
return
qry.Command("Select UID, Title, Content From ContentLinks ")
.Where("Category", category)
.OrderBy("Title")
.ReturnList<ContentPagesItem>();
// ^-- This is a simple table query but it could be any type of join, View or sproc call.
}
}
}
}
Во-вторых, легко добавить DAL/BLL DLLs к вашему проекту в качестве дополнительных проектов, а затем добавить ссылку на основной веб-проекта. Выполнение этого не только дает вашим DAL и BLL собственные идентификаторы, но и делает модульное тестирование.
В-третьих, я почти не признаю этого, но это может быть одно место, где Microsoft Entity Framework пригодится. Обычно мне не нравится Linq to Entities, но это позволяет указать спецификацию отношений данных, отсутствующих в вашей базе данных.
Наконец, я могу понять, почему изменений на вашу структуру db (например, движущиеся поля вокруг) было бы проблемой, но добавлять новые ограничения (особенно индексы) не должно быть. Они боятся, что внешний ключ в конечном итоге приведет к ошибкам в другом программном обеспечении? Если так ... это не такая хорошая вещь; вы должны иметь некоторую боль, чтобы знать, где лежит болезнь, нет?
По крайней мере, вы должны настаивать на возможности добавлять индексы по мере необходимости по соображениям производительности.Кроме того, я согласен с другими в том, что Views могут значительно продвинуться в создании более разумной структуры. Однако, этого действительно недостаточно в конечном итоге. Итак ... продолжайте и создавайте Views (Хранимые процедуры тоже), но вы должны еще избегать кодирования непосредственно в базе данных. В противном случае вы по-прежнему остаетесь привязкой вашей реализации к схеме базы данных и избежание ее в будущем будет сложнее, чем если вы изолируете взаимодействия db с DAL.
Я считаю, что техническое название шаблона проектирования здесь будет «хлопнуть сверху» –
Спасибо за выбор мой ответ, как * в * ответ. Я добавил немного больше кода, чтобы проиллюстрировать ObjectDataSources, так как вы его выбрали. –
@KM - разве это не анти-шаблон? Я также google'd SQL «Plop сверху», и эта страница была наверху. :) – Mayo