Проблема с LINQ в asp.net

Question

Я хотел бы реализовать LINQ IN ASP.NET для фильтрации требуемых данных из данных. Я сомневаюсь, что это правильное место. У меня есть следующие варианты

1. На уровне представления * .aspx.cs
2. На нашем бизнес-уровне.
3. На нашем уровне базы данных, где происходит запрос к базе данных, который возвращается в виде данных на бизнес-уровень. Затем бизнес-уровень возвращает результат на уровень представления.

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

Пожалуйста, помогите?

Answer 1

Linq можно использовать во всех слоях, но лучшее место для таких манипуляций - это бизнес-уровень. Это сделает код более понятным и легко распространяемым для дальнейшего использования на других страницах.

Answer 2

Если вы просто фильтруете свои данные с помощью linq (например, linq для объектов, linq для наборов данных) - вы можете использовать их на бизнес-уровне.

Если вы выполняете linq to sql и манипулируете данными, вы можете использовать его на уровне доступа к данным. Но если это слишком маленькое приложение, вы можете использовать его в любом слое.

Answer 3

Гемант, я думаю, что ваше критическое утверждение звучит так: «Мне нужно далее отфильтровать данные из данных в соответствии с пользовательскими фильтрами выбора». Первоначальный выбор данных, очевидно, должен исходить от вашего бизнес-уровня, чтобы: A) изолировать базу данных от пользовательского интерфейса и B) для реализации каких-либо бизнес-специфических правил для «подготовки» данных перед их доставкой в ​​пользовательский интерфейс.

Учитывая, что вы просто выбираете подмножества, основанные на взаимодействиях с пользователем, я думаю, что вполне логично поместить логику в пользовательский интерфейс. Действительно, это вполне может быть условием only , когда имеет смысл выполнять ориентированные на данные операции в пользовательском интерфейсе.

С учетом вышесказанного, я реализовал пользовательскую фильтрацию в специализированном классе в моем уровне бизнес-логики. Это разумно для меня, потому что вся пользовательская фильтрация имеет довольно специфическую направленность (она не распространяется на всю базу данных).

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

Answer 4

Почему бы вместо этого не попробовать ASP .NET MVC framework? Он построен на основе ASP .NET (так что вы получаете выгоду от всех его возможностей), плюс у вас есть слои с довольно хорошим разделением задач. Как ответили другие, лучший теоретический вариант - поместить код на бизнес-уровень. Это модельная часть структуры ASP .NET MVC.

Попробуйте, и ваш ответ возникнет естественным образом.