组织一个具有许多子应用程序的 Spring-mvc 项目
我从 Spring-mvc 中的一个项目开始，它基本上由 3 个部分组成
1) 前端
2) 后端（管理）
3) Web 服务
组织这些部分的最佳方式是什么，以便我可以重用域和 DAO 层尽可能地使用对象，同时将包分开（以避免同一个包中的 FrontendCategoryController 和 BackendCategoryController 等类名）？
另外，为所有这些部分提供通用配置和 pom.xml 文件是个好主意吗？
截至目前，我已经开始使用 maven 根据 webapp 原型生成的项目结构
编辑：
我正在考虑这样做的一种方法是 -
myapp
-- src
-- main
--java
--resources
-- backend
--java
-- resources
-- webservice
-- java
-- resources
在所有 java 目录中，包名称将相同
这是一种正确的方法吗
谢谢
I am starting with a project in Spring-mvc which basically is made up of 3 parts
1) Frontend
2) Backend (admin)
3) Web service
What would be best way to organize these parts so that I can reuse the domain and DAO layer objects wherever I can and at the same time keep the packages separate (so as to avoid class names such as FrontendCategoryController and BackendCategoryController in the same package) ?
Also would it be a good idea to have common config and the pom.xml file for all these parts ?
As of now I have started with the project structure generated by maven as per the webapp archetype
Edit:
One way I am thinking of doing this is -
myapp
-- src
-- main
--java
--resources
-- backend
--java
-- resources
-- webservice
-- java
-- resources
in all java directories, the package names will be same
Would this be a correct approach
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
首先，所描述的滥用 Maven 目录结构的方法看起来非常糟糕。
您说您希望避免长类名，例如
FrontendCategoryController和BackendCategoryController。您的设计似乎违反了“按功能打包，而不是按层打包” 规则。您可以为子应用程序创建单独的包，这样就不需要长类名。所有子应用程序使用的公共类可以放置在另一个包中。另一种方法是为不同的子应用程序创建单独的 Maven 项目，但看起来您不想要它。
First of all, depicted approach that misuses Maven directory structure looks really bad.
You say that you want to avoid long class names such as
FrontendCategoryControllerandBackendCategoryController. It looks like your design violates "Package by feature, not layer" rule. You can create separate packages for your subapplications, so that long class names wouldn't be needed. Common classes used by all subapplications can be placed in yet another package.Alternative approach would be to create separate Maven projects for different subapplications, but it looks like you don't want it.