я предлагаю что-то другое ... Используйте ленивый класс нагрузки:
public class Lazy<T>
{
T value;
Func<T> loader;
public Lazy(T value) { this.value = value; }
public Lazy(Func<T> loader { this.loader = loader; }
T Value
{
get
{
if (loader != null)
{
value = loader();
loader = null;
}
return value;
}
public static implicit operator T(Lazy<T> lazy)
{
return lazy.Value;
}
public static implicit operator Lazy<T>(T value)
{
return new Lazy<T>(value);
}
}
После того, как вы получите его, вы не нужно вводить дао в вас объект больше:
public class Transaction
{
private static readonly Lazy<Customer> customer;
public Transaction(Lazy<Customer> customer)
{
this.customer = customer;
}
public Customer Customer
{
get { return customer; } // implicit cast happen here
}
}
при создании объекта передам, не связанный с базой данных:
new Transaction(new Customer(..)) // implicite cast
//from Customer to Lazy<Customer>..
При регенерации транзакции из базы данных в хранилище:
public Transaction GetTransaction(Guid id)
{
custmerId = ... // find the customer id
return new Transaction(() => dao.GetCustomer(customerId));
}
Два происходят интересные вещи: - Ваши объекты домена могут быть использованы с или без доступа к данным, становится данных Acces невежественны. Единственное маленькое завихрение состоит в том, чтобы позволить передать функцию, которая дает объект вместо самого объекта. - Класс Lazy является внутренне изменчивым, но может использоваться как неизменяемое значение. Ключевое слово readonly сохраняет свою семантику, поскольку ее содержимое не может быть изменено внешним.
Если вы хотите, чтобы поле было доступно для записи, просто удалите ключевое слово readonly. при назначении нового значения новый Lazy будет создан с новым значением из-за неявного приведения.
Edit: Я писал о нем здесь:
http://www.thinkbeforecoding.com/post/2009/02/07/Lazy-load-and-persistence-ignorance
Может быть более элегантным, но это, как правило, реализация у меня есть время для. Он также оставляет ваш код открытым для какой-либо библиотеки более высокого уровня, чтобы обрабатывать ленивую загрузку путем отражения, если вы в этом верите. – ojrac 2009-02-06 22:51:33
То же замечание, что и выше: Инъекционные услуги (и особенно DAO) - это не очень хорошая идея. Это делает объект непригодным для использования без зависимости и делает его очень трудным для тестирования. Это сильно нарушает постоянство невежества. – thinkbeforecoding 2009-08-14 14:42:42
Я лично стараюсь избегать сценария, в котором может быть загружено свойство (`mSupplier`) *, но может и не быть. Это меня беспокоит каждый раз, когда я использую объект: кто-то загрузил его не полностью, т. Е. `MSupplier` имеет значение null, но это не должно было быть? Нужны ли нулевые проверки на `mSupplier`? У этих нулевых проверок есть вероятность запуска ленивой загрузки? (По общему признанию, я все еще ищу святого Грааля.) – Timo 2016-11-09 10:49:30