Представьте, что вы используете EntityFramework в качестве ORM, и все это заключено в отдельную библиотеку классов DAL.
У вас есть следующий объект POCO в другой «общей» библиотеке классов, которая хорошо используется вашим DAL, SL и уровнем представления:
public class User
{
public int Id { get; set;}
public string FirstName { get; set; }
public string LastName { get; set; }
public string Email { get; set; }
public int Age { get; set; }
public Gender Gender { get; set; }
}
Затем вы реализуете в SL следующее:
public interface IUserService
{
User GetById(int u);
List<User> GetByLastName(string s);
}
public class UserService : IUserService
{
private MyContext _myContext;
public UserService(MyContext myContext = null)
{
_myContext = myContext ?? new MyContext();
}
public User GetById(int userId)
{
return _myContext.Users.FirstOrDefault(u=>u.Id == userId);
}
public List<User> GetByLastName(string lastName)
{
return _myContext.Users.Where(u=>u.LastName == lastName).ToList();
}
}
И все работает отлично.
.
Но тогда вам нужно добавить в службу новый метод для обработки другого запроса (например, пользователей, попадающих в возрастной диапазон).
А затем другой.
И еще один...
.
Вскоре вы начинаете думать
Было бы неплохо, если бы вы могли предоставить любой запрос, который вы можете придумать, на уровень службы, и он получил бы соответствующие данные и вернул бы их для вас, без необходимости явно определять каждый возможный запрос как отдельный метод, много в так же, как SL уже делает с DAL?
Итак, вопрос:
Можно ли добиться этого БЕЗОПАСНО в пределах SL, сохраняя при этом слабую связанность? .
Я читал, что использование IQueryable может привести к катастрофе с такими вещами, как:
q.Where(x=>{Console.WriteLine("fail");return true;});
Но я также новичок в использовании ORM и уровней обслуживания, поэтому, естественно, я ищу «лучшие практики» и «известные ловушки», а также хочу, чтобы мой код оставался чистым.
