2) Да, связь учтена будет. Identity разрешается в точности, как в самом ЯП (по ссылке).
3) Информации по вопросам производительности и масштабируемости очень мало. Собственного исследования на данной момент также не проводил. Все, что могу сейчас дать, это ссылка на benchmark на сайте db4o. Сам объективность приведенных данных не проверял и не знаком с методикой тестирования.
1. Все верно, UoW более полное решение проблемы ORM. Но, чтобы его развернуть на уровне доменных объектов, требуется значительно больше усилий. На уровне LINQ to SQL UoW и так есть. На самом деле, предлагаемое решение что-то среднее между репозиторием и модулем таблицы.
2. Например, в веб-приложениях можно использовать Id, чтобы идентифицировать объект между двумя разными запросами.
Что касается операций GetAll, Save, Delete, то они сами по себе атомарны. GetAll соответствует одному запросу на чтение и, естественно, атомарен. Save и Delete, хоть и делают два запроса, тоже атомарны — если между двумя запросами происходит изменение соответствующей строки в БД, то кидается ChangeConfictException при вызове SubmitChanges.
Если требуется реализовать транзакционность на более высоком уровне, например, несколько подряд идущих Save, то можно использовать TransactionScope.
Все дело в том, что статическая классовая парадигма для многих разработчиков (далеко не всех!) является стандартом при разработке сложных приложений.
В случае client-side разработки у нас, практически, нет выбора. Надо использовать JavaScript.
Разве что есть ещё Google GWT. GWT решают ту же задачу, но на другом уровне.
Cпасибо за комментарий. Действительно, в JavaScript описания классов в стиле статических языков выглядят не лучшим образом. Все-таки, JavaScript — прототипный язык программирования.
Я использую такой стиль описания классов, потому что нотация статических языков мне привычнее и понятнее. Так же есть положительный опыт применения именно такой нотации на практике.
Повторений PageBase.prototype, действительно, можно избежать вот так:
Однако, так нельзя сделать в подклассах из-за особенностей OO.Extends.
Насчет исключений в абстрактных методах — это просто coding rule. Такие методы сразу видно в коде. Self-documented code. Никакой функциональной нагрузки тут нет.
Db4oFactory.Configure().ObjectClass(typeof(User)).Rename(«NewClassName»);
Db4oFactory.Configure().ObjectClass(typeof(User)).ObjectField(«Login»).Rename(«NewFieldName»);
Как ни странно, в Object Manager Enterprise визуальных средств для этого нет.
2) Да, связь учтена будет. Identity разрешается в точности, как в самом ЯП (по ссылке).
3) Информации по вопросам производительности и масштабируемости очень мало. Собственного исследования на данной момент также не проводил. Все, что могу сейчас дать, это ссылка на benchmark на сайте db4o. Сам объективность приведенных данных не проверял и не знаком с методикой тестирования.
2. Например, в веб-приложениях можно использовать Id, чтобы идентифицировать объект между двумя разными запросами.
Если требуется реализовать транзакционность на более высоком уровне, например, несколько подряд идущих Save, то можно использовать TransactionScope.
В случае client-side разработки у нас, практически, нет выбора. Надо использовать JavaScript.
Разве что есть ещё Google GWT. GWT решают ту же задачу, но на другом уровне.
Вариант: использовать jQuery.extend.
Для удобства выложил OO.js, содержащий метод Extends, в отдельный файл.
Я использую такой стиль описания классов, потому что нотация статических языков мне привычнее и понятнее. Так же есть положительный опыт применения именно такой нотации на практике.
Повторений PageBase.prototype, действительно, можно избежать вот так:
PageBase.prototype = { Init: function() {… }, _PageLoad: function() {… } }
Однако, так нельзя сделать в подклассах из-за особенностей OO.Extends.
Насчет исключений в абстрактных методах — это просто coding rule. Такие методы сразу видно в коде. Self-documented code. Никакой функциональной нагрузки тут нет.
вот, например, AJAX для мытья посуды.
1. Как будет выглядеть JavaScript через несколько лет?
2. Script#. Появится ли GWT от Microsoft?
3. Чем порадует VS2010 с точки зрения разработки client-side?