Легко: убедитесь, что у вас есть надежные слои доступа к данным и бизнес-логики. Вы должны избегать искушения программировать непосредственно в базу данных из ваших кодов ASPX!
Даже имея надежную схему базы данных, я теперь практикую никогда не работать с SQL в codebehinds - практику, которая развилась только после изучения сложного способа, который имеет свои недостатки.
Вот несколько советов, которые помогут процессу:
Сначала исследуйте класс 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 требует еще нескольких вещей, которые избавят вас от проблем с поиском в Google. Вот реализация, которая соответствует вызовам выше.
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 в ваш проект в качестве дополнительных проектов, а затем добавить ссылку на основной веб-проект. Это не только дает вашим DAL и BLL их собственные идентификационные данные, но и делает тестирование модулей несложным.
В-третьих, я почти не хочу это признавать, но это может быть одним из мест, где Microsoft Entity Framework пригодится. Обычно я не люблю Linq to Entities, но он разрешает спецификацию на стороне кода для отношений данных, которых вам не хватает в вашей базе данных.
Наконец, я понимаю, почему меняет на вашу структуру базы данных (например, перемещает поля вокруг), было бы проблемой, но добавление новых ограничений (особенно индексов) не должно быть. Они боятся, что внешний ключ приведет к ошибкам в другом программном обеспечении? Если так ... разве это не хорошо? тебе нужно немного болеть, чтобы знать, где лежит болезнь, нет?
По крайней мере, вы должны настаивать на возможности добавлять индексы по мере необходимости из соображений производительности. Кроме того, я согласен с другими, что представления могут иметь большое значение для создания структуры более разумной. Однако, этого действительно недостаточно в долгосрочной перспективе. Итак ... продолжайте и создайте Views (хранимые процедуры тоже), но вы должны все еще избегать кодирования непосредственно в базу данных. В противном случае вы по-прежнему привязываете свою реализацию к схеме базы данных, и в будущем ее избежать будет сложнее, чем если вы изолируете взаимодействия db с DAL.