GAE: Как эффективно отобразить объектно-ориентированные проекты в хранилище данных Appengine

Question

Предположим, что у меня есть следующая объектная модель (вы можете изменить ее так, как вам нравится, мой интерес - только эффективное отображение),

public class Product{
    private String someAttribute;
    //...
}

// A Seller who has a lot of products to sell, More than one Seller can sell the same Product
public class Seller{
    private List<Product> products;
    //...
}

public class Offer{
    // who is offering
    private Seller seller;
    // multiple products can make an offer
    private List<Product> products;
    // pricing related
    private Price price;
    //...
}

Я хочу написать вебПриложение, которое будет выполнять чтение, запись / поиск по этим объектам и рассматривать точку входа, может быть любым из них.

Ниже приведены мои запросы, -

1. Что такоешаблон дизайна, который я буду использовать?Я предполагаю, что какой-то шаблон адаптера?

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

   открытый класс Продавца {private List productKeys;}

3. Если я хочу написать масштабируемое и обслуживаемое приложение, я думаю, что должен быть какой-то хороший способ проектирования моего приложения в многоуровневой архитектуре.Есть ли какой-нибудь пример для этого или какой-то уже использованный шаблон?Например, какой-то JSP -> Сервис -> DAO -> хранилище данных?Примеры были бы очень благодарны.

Я прошел через AppEngineSDK для Java, но не нашел пример для того же.помощь в ответах или указателях действительно ценится.

Answer 1

С базами данных NoSQL (такими как GAE Datastore) вы должны думать с точки зрения модели доступа к данным, а не модели хранения данных.Т.е. вы должны думать о том, как вы будете получать доступ к данным и как вы будете организовывать данные так, чтобы доступ был наиболее эффективным (= быстрее и дешевле).

К сожалению, это часто идет вразрез с принципами ООП и «схемой» хранилища данных (тамРазве это не схема хранилища данных, вы понимаете, что не так?) не вписывается в парадигму ООП Java.

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

Теперь, поскольку вы не можете поместить все данные в одну запись, вам нужно сделать несколько уступок.Для этого вы должны решить:

1. Какие данные будут читаться чаще всего?
2. Какие данные будут изменены больше всего?

Из вашей модели I 'Я предполагаю, что Товар и Продавец не сильно изменятся, но Предложение будет часто создаваться, верно?Постарайтесь спроектировать так, чтобы минимизировать количество операций чтения / записи - начните с данных, которые используются чаще всего, и организуйте схему так, чтобы вы получали / помещали большую часть данных с минимальным количеством операций чтения / записи.

Попытка ответить на ваш вопросвопросы:

1. Просто создайте свой уровень обслуживания, где вы выполняете основные функции CRUD (добавление / обновление / удаление / поиск продавца / продукта / и т. д.) и бизнес-функции более высокого уровня (создание предложения дляПродавец с продуктами и т.д ..).DAO - это PITA, поэтому вы должны как можно больше работать с POJO - используйте Objectify.В этом случае вы можете покончить с шаблоном Адаптера.

2. Если под ссылками вы подразумевали идентификаторы (long, Long или String), то вам следует использовать ключи: ключи - это комбинация родительских ключей., вид и удостоверение личности.Ключи гарантированно будут уникальными, а идентификаторы - нет (они уникальны, только если вы не используете группы сущностей).Кроме того, с помощью objectify ключи являются типобезопасными, а идентификаторы - нет.

3. Как описано в 1., многоуровневый подход - это путь.Однако старайтесь избегать DAO - они требуют много ручной работы и, как таковые, являются источником ошибок.

Answer 2

Я бы взглянул на объективирование: http://code.google.com/p/objectify-appengine/

Как правило, практическое правило доступа к данным в appengine - избегать как можно большего количества «объединений». Извлечение больших (даже массивных) наборов данных из одной таблицы очень дешево в устройстве, но получение из множества мелких источников данных очень дорого. Таким образом, в вашем примере вы хотели бы рассмотреть возможность хранения продуктов в виде встроенных коллекций в таблице продавца, если вам это удастся.

НТН

Rick