わかりました。あなたの質問にポイントごとに答えてみましょう。最初に最後の質問に答えます。これにより、他の質問が自動的にクリアされます。
Q.また、Liferayがどのようなシナリオ/要件で役立つか知りたいです。
これには非常に幅広い答えがありますが、私はあなたのためにそれを短くしました：
- サイトのコンテンツが多く、データが多くない場合は、ポータルにアクセスしてください
- ポータルで単一のWebアプリケーションのみを使用することを計画している場合は、スタンドアロンのカスタム開発されたWebアプリケーションの方がはるかに優れていることをお勧めします。
私は、liferayポータルが、シングルサインオン、承認、認証、フレンドリURL、ページ作成などの多くの機能を提供し、ブログ、Wiki、ドキュメントライブラリ、一部のソーシャルネットワーキングアプリなどの多くのアプリケーションを提供することに同意します。しかし、それについて考えてみてください、あなたは本当にこれすべてが必要ですか？そうでなければ、これはやり過ぎです
ポータルの使用法をよりよく理解するためのいくつかの本当に素晴らしいリンクがあります：
- ポータルを使用する場合
- ポータルテクノロジーを使用する理由
- liferayタグwiki：liferayとは何かについてのわかりやすい説明があり、liferayのすべての機能とその管理方法を説明する管理ガイドへの関連リンクも含まれています。
それでも、他の質問に答えられていないことがわかった場合は、読み進めてください...
Q1。私たちがやろうとしていることは可能ですか？
いいえ。ポートレットテクノロジは、サーブレットテクノロジとは異なります。Liferay（または他のポータル）は、ポータル内でページをレンダリングするサーブレットを統合する方法（少なくとも単純なもの）を提供していません。例：サーブレットでは、特定のサーブレットのURLマッピングを事前にweb.xmlで定義しますが、ポータルでは、URLはポートレットコンテナによって生成されます。したがって、ポータルはサーブレットではなくポートレットで機能します。
Q2。このアプローチは、私たちが意図したことに対して推奨されますか？
いいえ。Q1ですでに説明したように。
Q3。それとも、Liferayに適合するために、プロジェクトを最初から開発する必要がありますか？ポートレットを開発し、LiferayまたはLiferayのドキュメントに記載されている他のアプローチで展開するようなものです。
あなたがライフレイの道を行きたいのなら、はい。
カスタムテーブルと通信するアプリケーションを構築する場合は、ポートレットが最適です。
Q4。データベース統合についてはどうですか？私たちのプロジェクトのデータベースのユーザーテーブルには、Liferayのユーザーテーブルとは完全に異なる約15の列/フィールドがあります。
Liferayを使用する場合。このシナリオでは、liferay-hook＆portlet（を使用している可能性がありますservice-builder）の組み合わせを作成して、Liferayのユーザー作成メカニズムをカスタマイズし、Liferayのユーザーテーブルとカスタムテーブルの両方にデータを保存できます。
Liferayの許可システムは非常にきめ細かいため、このシステムの恩恵を受けて、データレベルでも許可を与えることができます。
結論として、私は言うでしょう：
すべてはあなたの要件が何であるか、そしてあなたが持っているリソースは何かに要約されます。そして時々あなたが持つことができる将来の要件。
注：この回答で使用されているliferayに固有のすべての用語（サービスビルダー、フックなど）は、liferayタグwikiで説明されています。
お役に立てれば。具体的なことを知りたい場合は、喜んで回答を更新します。