为新手解释Java项目结构? [英] Java project structure explained for newbies?
问题描述
我来自.NET背景,对Java很新,我正试图了解Java项目结构。
I come from a .NET background and am completely new to Java and am trying to get my head around the Java project structure.
我的典型.NET解决方案结构包含表示逻辑上不同的组件的项目,通常使用以下格式命名:
My typical .NET solution structure contains projects that denote logically distinct components, usually named using the format:
MyCompany.SomeApplication.ProjectName
项目名称通常等于项目的根名称空间。如果它是一个大型项目,我可能会进一步打破命名空间,但更多时候我认为不需要进一步命名空间。
The project name usually equals the root namespace for the project. I might break the namespace down further if it's a large project, but more often than not I see no need to namespace any further.
现在在Java中,您拥有由项目组成的应用程序,然后您有了一个新的逻辑级别 - 包。什么是包裹?应该包含什么?你如何在这个 App.Project.Package
结构中命名空间? JAR在哪里适合所有这些?基本上,有人可以提供新的Java应用程序结构介绍吗?
Now in Java, you have applications consisting of projects, and then you have a new logical level - the package. What is a package? What should it contain? How do you namespace within this App.Project.Package
structure? Where do JARs fit into all this? Basically, can someone provide a newbies intro to Java application structure?
谢谢!
编辑: 一些真正破解的答案谢谢你们。然后是几个后续问题:
Some really cracking answers thanks guys. A couple of followup questions then:
- .JAR文件是否包含已编译的代码?或者只是压缩的源代码文件?
- 有没有一个很好的理由为什么包名都是小写?
- 包可以有循环依赖吗?换句话说,Package.A可以使用Package.B,反之亦然?
- 任何人都可以只显示声明一个类在一个包中的典型语法,并声明你希望引用一个类中的另一个包(可能是一个using语句吗?)
- Do .JAR files contain compiled code? Or just compressed source code files?
- Is there a good reason why package names are all lower case?
- Can Packages have 'circular dependencies'? In other words, can Package.A use Package.B and vice versa?
- Can anyone just show the typical syntax for declaring a class as being in a package and declaring that you wish to reference another package in a class (a using statement maybe?)
推荐答案
简单J2SE项目
As cletus解释说,源目录结构直接等同于包结构,而且它本质上是内置于Java中的。其他一切都不那么明确。
"Simple" J2SE projects
As cletus explained, source directory structure is directly equivalent to package structure, and that's essentially built into Java. Everything else is a bit less clear-cut.
很多简单的项目都是手工组织的,所以人们可以选择他们认为合适的结构。经常做的事情(这也反映在Eclipse中的项目结构,这是一个非常占主导地位的Java工具)是让您的源代码树开始于名为 src
的目录中。您的无包源文件将直接位于src中,并且您的包层次结构(通常以 com
目录开头)同样包含在 src
。如果你 CD
到 src
目录,然后启动 javac
编译器,您编译的 .class
文件将以相同的目录结构结尾,每个.class文件位于同一目录中,并且在旁边.java
file。
A lot of simple projects are organized by hand, so people get to pick a structure they feel OK with. What's often done (and this is also reflected by the structure of projects in Eclipse, a very dominant Java tool) is to have your source tree begin in a directory called src
. Your package-less source files would sit directly in src, and your package hierarchy, typically starting with a com
directory, would likewise be contained in src
. If you CD
to the src
directory before firing up the javac
compiler, your compiled .class
files will end up in the same directory structure, with each .class file sitting in the same directory and next to its .java
file.
如果您有很多源文件和类文件,您需要将它们彼此分开以减少它们混乱。手动和Eclipse组织经常将 bin
或类
目录与 src $ c并行放置$ c>所以.class文件最终形成一个层次结构,反映了
src
。
If you have a lot of source and class files, you'll want to separate them out from each other to reduce clutter. Manual and Eclipse organization often place a bin
or classes
directory parallel to src
so the .class files end up in a hierarchy that mirrors that of src
.
如果您的项目有一组 .jar
文件来提供第三方库的功能,然后是第三个目录,通常是 lib
,与 src
和 bin
并行放置。需要将 lib
中的所有内容放在类路径上进行编译和执行。
If your project has a set of .jar
files to deliver capability from third-party libraries, then a third directory, typically lib
, is placed parallel to src
and bin
. Everything in lib
needs to be put on the classpath for compilation and execution.
最后,有一堆这样的以及或多或少是可选的:
Finally, there's a bunch of this and that which is more or less optional:
-
doc
中的文档> - 资源
资源
-
数据中的数据
- 配置
conf
...
- docs in
doc
- resources in
resources
- data in
data
- configuration in
conf
...
你明白了。编译器不关心这些目录,它们只是让你自己组织(或混淆)的方法。
You get the idea. The compiler doesn't care about these directories, they're just ways for you to organize (or confuse) yourself.
J2EE大致相当于ASP.NET,它是用于组织Web应用程序的大型(标准)框架。虽然您可以按照自己喜欢的方式开发J2EE项目的代码,但Web容器希望您的应用程序交付的结构有一个坚定的标准。而且这种结构往往也会反映出源代码布局。
这是一个详细介绍Java项目项目结构的页面(它们与我上面写的内容不太一致),特别是J2EE项目:
J2EE is roughly equivalent to ASP.NET, it's a massive (standard) framework for organizing Web applications. While you can develop your code for J2EE projects any way you like, there is a firm standard for the structure that a Web container will expect your application delivered in. And that structure tends to reflect back a bit to the source layout as well. Here is a page that details project structures for Java projects in general (they don't agree very much with what I wrote above) and for J2EE projects in particular:
http://maven.apache。 org / guides / introduction / introduction-to-standard-directory-layout.html
Maven
是一个非常通用的项目构建工具。就个人而言, ant
很好地满足了我的构建需求,大致与 nmake
相比。另一方面,Maven是完整的生命周期构建管理,依赖于管理依赖性管理。 Java世界中大多数代码的库和源代码都是免费提供给'net,maven,如果问得好的话,它会为你抓取它并将你需要的所有项目带回家,而不需要告诉它。它也为你管理一个小仓库。
Maven
is a very versatile project build tool. Personally, my build needs are nicely met by ant
, which roughly compares with nmake
. Maven, on the other hand, is complete-lifecyle build management with dependency management bolted on. The libs and source for most of the code in the Java world is freely available in the 'net, and maven, if asked nicely, will go crawling it for you and bring home everything your project needs without you needing to even tell it to. It manages a little repository for you, too.
这个高度勤奋的生物的缺点是它对项目结构非常具有法西斯主义的事实。你按照Maven的方式做到或不做。通过强迫其标准,Maven设法使全球项目在结构上更加相似,更易于管理,并且更容易以最少的输入自动构建。
The downside to this highly industrious critter is the fact that it's highly fascist about project structure. You do it the Maven way or not at all. By forcing its standard down your throat, Maven manages to make projects worldwide a bit more similar in structure, easier to manage and easier to build automatically with a minimum of input.
如果您选择Maven,您可以不再担心项目结构,因为只能有一个。就是这样: http://maven.apache .org / guides / introduction / introduction-to-standard-directory-layout.html
Should you ever opt for Maven, you can stop worrying about project structure, because there can only be one. This is it: http://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
这篇关于为新手解释Java项目结构?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!