Лучшая практика для сохранения / публикации при создании веб-контента - PullRequest
4 голосов
/ 13 сентября 2011

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

В прошлом я делал этодля сайта публикации блога, где сообщения имеют черновой объект, который создается или удаляется в зависимости от того, что происходит в потоке сохранения / публикации,

Интересно, какие другие подходы могут работать лучше.Есть ли шаблон дизайна для такого рода вещей?

По проектам они довольно большие, разделены на 5 страниц для ввода, каждая страница может быть сохранена или опубликована.

1 Ответ

1 голос
/ 13 сентября 2011

Конкретный дизайн для черновика или публикации или постановки против производства - это в основном абстракция уровня источника данных. В основном уровень данных разделен на две реализации с одинаковым интерфейсом.

Вот очень простой интерфейс того, что две реализации (черновой и опубликованный) источника данных могут использовать


public interface CMSDatasource {
    /***
     * Save the data
     * @param data the data needed to be saved
     * @return The key for the data
     */
    public String saveData(String data);

    /***
     * Delete the data given a particular key
     * @param key
     */
    public void deleteData(String key);

    /***
     * Get the data given a particular key
     * @param key
     * @return
     */
    public String getData(String key);

    /***
     * Get all the data that has been put into the system
     * @return Return a Map of timestamp and the String being put 
     * into the system
     */
    public Map getHistory(); 
}

Теперь оба источника данных для черновика / публикации должны быть в состоянии сделать эти вещи в любом случае, единственное, что различает их, - это место, где они будут храниться.

Также обратите внимание, что эти два оперируют одним и тем же типом данных (в данном случае String), поэтому их необходимо нормализовать на логическом уровне CMS.

Используя этот дизайн, нам не нужно переписывать модуль логики для CMS или модель данных. Все, что нам нужно сделать, это поменять источник данных между черновиком и опубликованным. Чтобы получить соответствующий источник данных, мы могли бы реализовать шаблон Factory.

Абстрагирование источника данных через интерфейс также позволило бы реализации свободно выбирать базовую реализацию источника данных. Например, вы можете выбрать реляционную базу данных, такую ​​как MySQL, для хранения черновика, но вы можете решить использовать NoSQL, такой как CouchDB, для хранения опубликованных данных. Создавая интерфейс через источник данных, легко перенести источник данных из одной реализации в другую.

Для дальнейшей иллюстрации, давайте предположим, что очень простой модуль статьи в CMS, который будет содержать статью, которую может ввести пользователь. Класс будет выглядеть примерно так:


public class ArticleModule {
    String article;
    int publishingMode;

    /***
     * Save the data based on user's action 
     */
    public void saveData() {
        // get the datasource depending on the publishing mode set for this 
        // module (DRAFT vs. PUBLISHED)
        CMSDatasource datasource = CMSDatasourceFactory.getDatasource(publishingMode);

        // save the article, note that nothing is required to change in this class
        // since the datasource is completely abstracted by the interface
        datasource.saveData(article);
    }

    // below is the getter/setter for the article and publishing mode
    // ......  
}

Чтобы создать статью, пользователи CMS будут взаимодействовать с этим классом, устанавливая статью, которую они помещают через пользовательский интерфейс. Когда пользователь будет готов к сохранению, пользовательский интерфейс в конечном итоге вызовет saveData, обратите внимание, что в этой реализации нам не нужно изменять какой-либо код статьи, независимо от того, находится ли он в черновом режиме или в режиме публикации, так как Factory абстрагировала реализацию источника данных .

И, наконец, вот скелет для Фабрики


public class CMSDatasourceFactory {
    public static final int DRAFT_MODE = 1;
    public static final int PUBLISHED_MODE = 2;

    /***
     * Get a specific implementation of the datasource based on publishing mode
     * @param publishingMode Either draft or published mode, 
     * use the constant DRAFT_MODE or PUBLISHED_MODE
     * @return A specific implementation for the datasource wrapped in CMSDatasource interface
     */
    public static CMSDatasource getDatasource(int publishingMode) {
        switch(publishingMode) {
            case CMSDatasourceFactory.DRAFT_MODE :
                return new CMSDraftDatasource();
            case CMSDatasourceFactory.PUBLISHED_MODE:
                return new CMSPublishedDatasource();
        }

        return null;
    }
}
...