Можно ли совершать звонки на уровень данных / репо из POCO? - PullRequest
0 голосов
/ 23 мая 2011

Я пытаюсь выяснить, как настроить чистую архитектуру для моей корзины покупок, не перегружая ее архитектурой и не заканчивая анемичной моделью предметной области. Прямо сейчас я просто хочу использовать стандартную логику базы данных ADO без какой-либо инфраструктуры ORM. (Я также изучаю EF4.1, но еще недостаточно хорош для использования в производстве)

В идеале, я бы просто имел POCO для каждого бизнес-объекта / сущности и репозиторий / класс данных, который будет обрабатывать постоянство. Для простоты я думаю тесно связать POCO с уровнем данных, и он вернет POCO. Если я добавлю DTO к миксу, я получу 5-6 файлов классов для каждой области (gc, order, items, payment и т. Д.), Что кажется слишком большим для простого приложения. Я всегда могу уточнить позже.

Первый класс, над которым я работаю, - это подарочные сертификаты. Одним из методов является создание нового GC. В этом методе мне нужно будет запросить базу данных, чтобы убедиться, что новый код еще не существует в системе. Можно ли просто вызывать слой данных / репо внутри этого метода?

Должен ли уровень данных / репо быть статическим? Стоит ли выставлять его только через самого POCO?

Стоит ли вообще отбрасывать слой данных и просто передавать вызовы данных прямо в мои POCO (стиль активной записи)?

Мне нужна простая архитектура, которая позволит мне разделить проблемы, не усложняя ситуацию. Поставщик базы данных и структура таблиц не изменятся, по крайней мере, в течение следующих нескольких лет.

Вот код ... просто нужно выяснить, куда идут детали.

public GiftCertificateModel
{
    public int GiftCerticiateId {get;set;}
    public string Code {get;set;}
    public decimal Amount {get;set;}
    public DateTime ExpirationDate {get;set;}

    public void Redeem(string code, decimal amount)
    {
        //need to validate the input
        //need to insert a record to the transaction log table (call the repo or does this entire method need to be in the repo?)
    }

    public void GetNewCode()
    {
        //need to create random alpha num code
        //need to make sure the code is unique in the db... (again, (call the repo or does this entire method need to be in the repo?
    }

}




public GiftCertificateRepo : DALBase (DALBase has methods for connecting, etc)
{

    //mapping code here to map SQLDataReader values to GiftCertificateModel properties
    //i can also setup separate DTOs if it makes more sense...

    //should the repo be static?
    public static GiftCertificateModel GetById(int GiftCertificateId)
    {
        //call db to get one and return single model

    }

    public static bool IsUnique(string code)
    {
        //call db to see if any records exists for code

    }

    public static List<GiftCertificateModel> GetMany()
    {
        //call db to get many and return list

    }

    public static void Save(GiftCertificateModel gc)
    {
        //call db to save

    }
}

Телефонный код:

GiftCertificateModel gc = new GiftCertificateModel();
gc.Code = gc.GetNewCode(); //do i call the is unique here or in the GetNewCode method?
gc.Amount = 10;
gc.ExpirationDate = "1/1/2012";
GiftCertificateRepo.Save(gc);

Ответы [ 3 ]

5 голосов
/ 23 мая 2011

По определению, POCO - невежественное упорство, то есть оно не знает этого и как оно сохраняется.

Если вы связываете свои бизнес-объекты со своими репозиториями или постоянным слоем, это может быть прекрасно, в зависимости от ваших обстоятельств, но это больше не будет POCO.

2 голосов
/ 23 мая 2011

Существует несколько систем / идеологий, но все они согласны с тем, что постоянство не является частью бизнес-класса.Создайте отдельный уровень доступа к данным для хранения и извлечения ваших POCO.

1 голос
/ 23 мая 2011

Сохраняя POCO (представления данных) отдельно от объектов репозитория (представления о том, как данные хранятся / извлекаются), вы в будущем сможете гораздо легче переключаться с ADO на более продвинутую систему ORM - эти коды изменения будут изолированы в одном месте.

Еще лучше, определите интерфейс IRepository и сделайте так, чтобы ваш класс хранилища ADO реализовал его. Тогда ваше приложение должно работать только с IRepository, что еще больше упростит тестирование или переключение реализаций репозитория.

...