Микро-ORM своими руками (часть первая)

[datacompboy]

А при чем тут ORM?

[VolCh]

Слово модное :)

[dimzon541]

При том что это пока только первая часть статьи.

[VolCh]

Может стоило тогда начать именно с маппинга таблиц на POJO (в идеале) и наоборот, а не с поддержки подготовленных выражений «как хочется»? Или, хотя бы, упомянуть его во вступлении?

[dimzon541]

Ну идем от простого к сложному, тут цель была ознакомить читателя с паттерном «стратегия» потому что на нем все построено. А во вступлении сказано — «аналог Dapper.NET» — это библиотечка под .NET, которая маппит результат выполнения запроса в POCO, называется микро-ORM.

[vip_delete]

В JDBC есть метод setObject, поэтому свом методы setXXX можно было бы не писать.

>strings[i] = ((Boolean) arg)? «1»: «0»;

postgresql, очевидно, ORM поддерживать не будет?

[dimzon541]

Будет :) Помним про расширяемость:

DB.registerParamFactory(Boolean.class, new FN<Boolean, Param>() {
	public Param apply(final Boolean input) throws Exception {
		return new Param() {
			public void set(PreparedStatement preparedStatement, int index) throws SQLException {
				if (input == null) preparedStatement.setNull(index, Types.BOOLEAN);
				else preparedStatement.setBoolean(index, input);
			}
		};
	}
});

[nocach]

простота и атомарность — библиотечка представляет собой 1 java-файл, для добавления в проект достаточно просто добавить файлик к своим исходникам.

Если это не является самым главным критерием, то можно использовать spring-jdbc
Делает во многом тоже самое. Если используете maven, достаточно будет прибавить к проекту только зависимость

<dependency>
    	<groupId>org.springframework</groupId>
    	<artifactId>spring-jdbc</artifactId>
    	<version>...</version>
</dependency>

[dimzon541]

Ещё есть commons.apache.org/dbutils/
Но свое написать интересней для самообразования — я с .NET на Java переучиваюсь :)

[mcgede]

Ну да, велосипеды то интересней делать.

[mcgede]

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

В каждом проекте находился как минимум один «изобретатель-выдумщик».
Пример №1. люди использовали spring mvc контроллер, не удосужившись изучить документацию. Результат: 2500 строк кода.
Пришел нормальный программист и переписал это. Результат: 200 строк кода при той же функциональности.

Пример №2. Люди взяли и написали свою реализацию jms. Зачем, ответить не могут. Кстати, реализовали с ошибками.

На мой взгляд, изобретать надо тогда, когда существующие решения не устраивают.

[nocach]

Мне кажется автор знает об альтернативах. И, возможно он ими и пользуется.

Не вижу проблем в написании собственного велосипеда в целях самообразования при переходе с .net на java. Если тема велосипеда интересна, то и писать будет не скучно. Если будет писать не скучно, то быстрее изучишь и вероятнее глубже, чем поверхностное шаблонное кодирование простых примеров.

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

[mcgede]

Как то логически не стыкуется. Если автор знает альтернативы, то уровень у него не ученический.

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

[dimzon541]

1. У автора в подчинении 8 бойцов, коих он (автор) учит мыслить абстрактно и в паттернах.
2. У автора за плечами 10 лет .NET, сертификат MCPD:EAD и пр.
3. Автор выступал ведущим разработчиком нескольких поколений framework-а для крупного российского интегратора, в том числе разрабатывал ORM, не имеющий на данный момент аналогов.
4. Автор посмотрел существующее решение и остался недоволен реализацией Spring JDBCTemplate.

[mcgede]

1. Говорить о себе в третьем лице — это сильно)))
У меня бойцов бывало и больше и это ни о чем не говорит.

2. У меня на собеседовании бывали специалисты с сертификатами. Из 5-х собеседование прошел один. Фирма на тот момент — Люксофт. Сертификаты не есть показатель…

3. Не буду спорить о целесообразности писания своего фреймворка да еще для крупного интегратора. Возможно она была, но я сильно настораживаюсь, когда говорят в ключе «не имеющий на данный момент аналогов». Еще раз напомню пример из своей жизни, когда люди, работающие на большого системного интегратора, написали свой jms. Наш с ними диалог:
Я: зачем написали свое, а не использовали то, что есть на рынке?
Они, смотрели аналоги и не понравилось.
Я: и чем ваше отличается от jms?
Они: а что это такое?

А еще они это г-внище патентуют.
Так что написание своего фреймворка без большого комьюнити не аргумент крутости. Ну по крайней мере для меня.

4. Spring JDBCTemplate разве является ORM-ом?
Чем вас не устраивают уже написанные ORM? Как много вы их посмотрели?
Список не мал.

[rachiu]

При этом автор не умеет аргументированно вечти спор и пользоваться терминологией.

[yroman]

По-моему тащить за собой чуть ли не весь спринг ради одного jdbc не есть рационально.