Платформа объекта как репозиторий и UnitOfWork?
Если я хорошо помню, парсер Stanford представляет собой библиотеку java, поэтому на вашем сервере / компьютере должен быть Java-интерпретатор.
Я использовал его один раз на сервере в сочетании с php-скриптом. Сценарий использовал функцию exec () php для вызова командной строки для синтаксического анализатора следующим образом:
<?php
exec( "java -cp /pathTo/stanford-parser.jar -mx100m edu.stanford.nlp.process.DocumentPreprocessor /pathTo/fileToParse > /pathTo/resultFile 2>/dev/null" );
?>
Я не помню всех деталей этой команды, она в основном открывала fileToParse, анализировалась он, и написал вывод в файле результатов. PHP затем откроет файл результатов для дальнейшего использования.
Конец команды направляет подробный отчет парсеру NULL, чтобы предотвратить ненужную информацию из командной строки от нарушения сценария.
Не знаю много о Python, но может быть способ сделать вызовы командной строки.
Возможно, это не тот точный маршрут, на который вы надеялись, но, надеюсь, это даст вам некоторое вдохновение. Удачи.
2 ответа
Я не думаю, что Платформа Объекта является хорошей реализацией Репозитория, потому что:
- контекст объекта недостаточно абстрактен, чтобы сделать хорошее поблочное тестирование вещей, которые ссылаются на него, так как это связывается с доступом DB. Наличие ссылки IRepository вместо этого работает намного лучше на создание модульных тестов.
- , Когда у клиента есть доступ к ObjectContext, клиент может сделать в значительной степени что-либо, чему он заботится. Единственный реальный контроль, который Вы имеете над этим вообще, должен сделать определенные типы или свойства частными. Трудно реализовать хорошую безопасность данных этот путь.
- На нетривиальной модели, ObjectContext недостаточно абстрактен. У Вас могут, например, быть и таблицы и хранимые процедуры, отображенные на том же типе объекта. Вы действительно не хотите, чтобы клиент должен был различать эти два отображения.
- На связанной ноте, трудно записать всесторонний, и хорошо - осуществляют бизнес-правила и код сущности. Действительно, действительно ли это, это - даже хорошая идея, спорно.
, С другой стороны , после того как у Вас есть ObjectContext, реализовывая шаблон Репозитория, тривиально. Действительно, для случаев, которые не особенно сложны, Репозиторий является чем-то вроде обертки вокруг ObjectContext и типов Объекта.
Я сказал бы, что необходимо посмотреть на ObjectContext как UnitOfWork, и не как репозиторий.
ObjectContext не может быть репозиторием - по-моему-скромному-мнению, так как это 'к универсальному'. Необходимо создать собственные Репозитории, которые имеют специальные методы (как GetCustomersWithGoldStatus, например) рядом с обычными методами CRUD.
Так, то, что я сделал бы, создают репозитории (один для каждого совокупного корня) и позволяют тем репозиториям использовать ObjectContext.