Вы используете MDA/MDD/MDSD, какой-либо вид управляемого моделью подхода? Это будет будущее?

Question

Вы используете MDA/MDD/MDSD, какой-либо вид управляемого моделью подхода? Это будет будущее?

В хорошо разработанном подходе MVC файл JSP не должен содержать строку Java-кода, и класс сервлета не должен содержать строку JDBC-кода.

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

Класс Product, представляющий объект реального мира продукта, должен быть просто Javabean ,

public class Product {

    private Long id; 
    private String name;
    private String description;
    private BigDecimal price;

    // Add/generate getters/setters/c'tors/equals/hashcode boilerplate.
}

Класс DAO , который выполняет всю неприятную работу JDBC и возвращает приятный List.

public class ProductDAO {

    private DataSource dataSource;

    public ProductDAO(DataSource dataSource) {
        this.dataSource = dataSource;
    }

    public List list() throws SQLException {
        List products = new ArrayList();

        try (
            Connection connection = dataSource.getConnection();
            PreparedStatement statement = connection.prepareStatement("SELECT id, name, description, price FROM product");
            ResultSet resultSet = statement.executeQuery();
        ) {
            while (resultSet.next()) {
                Product product = new Product();
                product.setId(resultSet.getLong("id"));
                product.setName(resultSet.getString("name"));
                product.setDescription(resultSet.getString("description"));
                product.setPrice(resultSet.getBigDecimal("price"));
                products.add(product);
            }
        }

        return products;
    }

}

Класс сервл , который получает список и помещает его в область запроса.

@WebServlet("/products")
public class ProductsServlet extends HttpServlet {

    @Resource(name="jdbc/YourDB") // For Tomcat, define as  in context.xml and declare as  in web.xml.
    private DataSource dataSource;
    private ProductDAO productDAO;

    @Override
    public void init() {
        productDAO = new ProductDAO(dataSource);
    }

    @Override
    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        try {
            List products = productDAO.list();
            request.setAttribute("products", products); // Will be available as ${products} in JSP
            request.getRequestDispatcher("/WEB-INF/products.jsp").forward(request, response);
        } catch (SQLException e) {
            throw new ServletException("Cannot obtain products from DB", e);
        }
    }

}

Наконец, файл JSP в /WEB-INF/products.jsp, который использует JSTL для итерации по List, который доступен в EL на ${products} и использует JSTL , чтобы избежать свойств строки, чтобы избежать отверстий XSS , когда речь идет о входном сигнале, управляемом пользователем.
```
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/format" prefix="fmt" %>
...

        
    
            ${product.id}
            
            
            
        
    
```

Чтобы заставить его работать, просто вызовите сервлет по его URL-адресу. При условии, что сервлет аннотируется @WebServlet("/products") или отображается в web.xml с помощью /products, вы можете называть его http://example.com/contextname/products

См. Также:

7

model-driven paradigms

задан Martin Klinke 21 August 2008 в 22:10

9 ответов

Образцовая Управляемая разработка была вокруг в течение очень долгого времени.

Большей частью succesfull ранних попыток был James Martins Интегрированное Инженерное средство", которое является все еще вокруг и продано CA под серьезно некрутой торговой маркой "Coolgen".

Итак, почему это не приняло мир, если это было настолько хорошо?

Хорошо эти инструменты способны делать простой материал более простым, но, они не делают сложные вещи немного легче, и во многих случаях делают сложные вещи тяжелее!

Можно провести часы, пытаясь убедить диаграмму 4GL язык моделирования "сделать правильную вещь", когда Вы знаете, что кодирование правильной вещи в Java/C/SQL или независимо от того, что было бы тривиально.

5

ответ дан 6 December 2019 в 08:17

Одна из проблем MDD - то, что, так как он работает на более высоком уровне абстракции, он требует разработчиков, которые могут подняться на уровне абстракции также. Это значительно уменьшает вселенную разработчиков, которые могут понять и использовать такие методологии.

2

ответ дан 6 December 2019 в 08:17

Я думаю, возможно, нет категорического ответа - следовательно отсутствие "интереса" к этому вопросу.

Но у меня лично был смешанный опыт с MDA. Единственное время это был хороший опыт, было с большими инструментами - я раньше использовал TogetherSoft (я полагаю, что они так или иначе закончили в Borland) - они были одним из первых для представления редактирования, которое не было "генерацией кода", но на самом деле редактированием кода/модели непосредственно (таким образом, Вы могли отредактировать код или модель, это была вся одна вещь). У них также был рефакторинг (который был первым разом, когда я помню, что он отправляет smalltalk среды).

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

Конечно, популярность не все и вещи иметь тенденцию возвратиться, но в настоящее время я думаю, что MDA+tools просматривается многими как "основанная на мастере генерация кода" инструменты (независимо от того, что это действительно), таким образом, я думаю, что будет проходить некоторое время или возможно никогда, что это действительно взлетает.

3

ответ дан 6 December 2019 в 08:17

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

Я думаю, что MDSD все еще очень связывается с генерацией кода.

Генерация кода только полезна, когда Ваш код содержит много шума и/или является очень повторяющимся. Другими словами, когда Ваш код не может главным образом сфокусироваться на существенной сложности, но загрязнен случайной сложностью.

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

Таким образом, эти новые платформы/платформы вынимают много ветра из парусов перемещения MDSD.

DSLs (текстовые) являются другой тенденцией, которая пытается включить единственное внимание на существенную сложность. В то время как DSLs может использоваться в качестве источника для генерации кода, они, прежде всего, не связываются с генерацией кода. DSLs (особенно внутренний DSLs) в основном позволяют ему открыться, чтобы быть интерпретированным/выполненным во времени выполнения. [генерация кода во время выполнения где-нибудь промежуточная].

Таким образом, даже если DSLs часто упоминаются вместе с MDSD, я думаю, что они - действительно альтернатива MDSD. И, учитывая текущую шумиху, они также вынимают импульс из перемещения MDSD.

Если Вы достигли цели окончательного удаления случайной сложности из Вашего кода (я знаю, что это является фиктивным), то Вы прибыли в текстовую модель своей бизнес-проблемы. Это не может быть далее упрощено!

Хорошие поля и схемы не предлагают другое упрощение или повышение уровня абстракции! Они могут быть хороши для визуализации, но даже который сомнителен. Изображение является не всегда лучшим представлением для схватывания сложности!

Далее больше текущее состояние инструментов, привлеченных в MDSD, добавляет, другой уровень случайной сложности (думайте: синхронизация, diffing/merging, осуществляя рефакторинг...), который в основном аннулирует конечную цель упрощения!

Посмотрите на следующую модель ActiveRecord как иллюстрация моей теории:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Я не думаю, что это может больше упрощаться. Также любое графическое представление с полями и строками не было бы никаким упрощением и не будет больше предлагать удобства (думайте о layouting, рефакторинге, поиске, diffing...).

6

ответ дан 6 December 2019 в 08:17

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

Я думаю, что участники здесь являются частью "Никакой Серебряной пули" лагерь (я определенно). Если бы MDA работал (равняется "огромным сбережениям"), мы знали бы это, который является наверняка. Вопрос: как далеко "meta" можно пойти при сохранении системы управляемой? Это было поворотным моментом в UML 2.0, когда они представили более формальную метаметамодель. До сих пор я не видел использование реального мира modelisation питания UML 2.0 (но мой мир скорее ограничен). Кроме того, у Вас есть только два варианта с управляемым моделью подходом: сгенерируйте код или наличие времени выполнения, использующего Вашу модель. Окончательный генератор кода без ограничений называют "человеческим", тогда как окончательное время выполнения, где найдено в 4GLs (каково текущее число в наше время?). Возможно, это объяснило бы отсутствие enthousiasm.

1

ответ дан 6 December 2019 в 08:17

Мы, в itemis (www.itemis.com) используем управляемую моделью Разработку программного обеспечения много. До сих пор у нас были действительно хорошие события. Shure это не серебряная пуля, но это помогает улучшающемуся качеству программного обеспечения следовательно больше использования для наших клиентов.

1

ответ дан 6 December 2019 в 08:17

Образцовая Управляемая Разработка будет будущим, если и только если модели, которые это использует, могут быть столь же гибкими как написание кода, который это, как предполагается, генерирует. Я думаю причина, почему она не так успевает, прямо сейчас то, что Вы, трудно сделать то же "круглое смещение", которое основанные на тексте языки программирования делали в течение многих десятилетий.

С основанными на тексте языками программирования, изменяя модель так же просто как изменяющий несколько строк кода. С графическим языком программирования (иначе MDD-схема как UML), необходимо найти, что способ перевести ту модель полностью отступает к ее основанному на тексте эквиваленту (который был уже выразительно эффективен во-первых), и это может быть очень, очень грязно.

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

1

ответ дан 6 December 2019 в 08:17

Это очень запоздалый ответ, но в настоящее время я ищу инструменты MDD для замены Rose RT, которые, к сожалению, заменяются Rhapsody. Мы находимся в реальном времени, встраиваемом и распределенном пространстве C ++, и мы получаем МНОГО от MDD. Мы пытаемся перейти к более совершенному инструменту и более широко использовать его в нашей очень большой компании. Это тяжелая битва из-за некоторых прекрасных причин, упомянутых здесь.

Я думаю, что MDD находится всего на один уровень выше компилятора, так же как компилятор находится выше сборки. Мне нужен инструмент, который позволяет мне, как архитектору, разрабатывать структуру приложения и широко редактировать генерацию кода (скрипты) для использования этой структуры и любого промежуточного программного обеспечения, которое мы используем для передачи сообщений. Я хочу, чтобы разработчики создавали полные классы UML и диаграммы состояний, которые включают весь код, необходимый для создания приложения и / или библиотеки.

Это правда, что с кодом можно делать все, что угодно, но я бы грубо резюмировал преимущества MDD как это:

Некоторые люди создают платформу приложения, адаптеры промежуточного программного обеспечения и приклеивают их к инструменту MDD. Они строят «дом».
Другие люди создают полные классы, диаграммы и код перехода конечного автомата. Это позволяет им сосредоточиться на приложении, а не на «доме».
Это легко увидеть, когда люди имеют странный дизайн, поскольку диаграмма - это код. У нас нет всех опытных разработчиков, и приятно поднять таким образом молодых людей.
В основном это неприятный код конечного автомата, который может случиться в чем-то вроде проекта мобильной робототехники. Я хочу, чтобы люди делали диаграммы состояний, которые я могу понять, критиковать и с ними работать.
Вы также можете провести хороший рефакторинг, например, перетаскивать операции и атрибуты вверх по цепочкам наследования или в другие классы и т. Д. Мне это нравится больше, чем копаться в файлах .

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

Основная проблема, с которой я сталкиваюсь, на которую у меня нет хорошего ответа, заключается в том, что не существует стандарта набор функций и формат файлов для таких моделей. Люди беспокоятся о том, что продавец уйдет, а затем застрянет. (В основном это случилось с Rose RT.) У вас этого нет с исходным кодом. Однако, у вас будет последняя версия инструмента и код курса, который вы создали последним :). Я готов поспорить, что выгода перевешивает риск.

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

0

ответ дан 6 December 2019 в 08:17

Другие вопросы по тегам:

model-driven paradigms

Вы используете MDA/MDD/MDSD, какой-либо вид управляемого моделью подхода? Это будет будущее?

См. Также:

9 ответов

Похожие вопросы: