Questions tagged «project-structure»

3
按类型的文件夹或按功能的文件夹
我利用了AngularJS样式指南。在本指南中，有一种称为的样式folder-by-feature，而不是folder-by-type，我很好奇什么是最佳方法（在此示例中为Java） 假设我有一个应用程序，可以在其中使用服务，控制器，存储库以及当然的域对象来检索“用户和宠物”。 以文件夹.....样式为例，对于包装结构，我们有两个选择： 1.文件夹类型 com.example ├── domain │ ├── User.java │ └── Pet.java ├── controllers │ ├── UserController.java │ └── PetController.java ├── repositories │ ├── UserRepository.java │ └── PetRepository.java ├── services │ ├── UserService.java │ └── PetService.java │ // and everything else in the project └── MyApplication.java 2.按功能文件夹 com.example ├── …
3
我们应该在同一解决方案中从MVC应用程序调用Web API吗？
我正在MVC中具有移动应用程序的项目中工作，因此很明显，我们必须使用Web API，以便可以在移动应用程序中使用它。 在开始开发网站时创建了API之后，我们感到困惑，并讨论了是使用API​​还是直接访问Business对象。最后，我们让更多有经验的开发人员来使用Web API，而不是直接使用Business对象。 我对此解决方案结构感到困惑。 1）为什么我们应该使用Web API并发出HTTP请求（这很耗时）来获取或放置数据，而不是直接使用相同解决方案中的业务对象。 2）在争论之后，他们说如果客户端要在不同的云服务器上托管API和Web并仅在API上应用扩展，或者他想为访问API和Web使用不同的url（这是合理的）。因此，在那种情况下，我们应该在同一解决方案中从MVC应用程序调用Web API吗？ 3）如果我们将API和Web托管在不同的托管上，那么这意味着我们的Web将使用WebClient并在每个导航上都有HTTP调用。这样对吗？ 4）如果我们要在不同服务器上同时使用API​​和Web托管的业务对象，则BL中的某些更改将需要更新这两个服务器上的构建。 5）或者我们应该只为API创建一个项目，并且可以添加视图或html页面来开发Web界面，这样我们就可以直接从ajax调用API。 据我所知，＃5是最好的解决方案，或者API仅适用于第三方访问。如果我们在同一解决方案中具有DB，EF，数据层和业务层，则我们不应使用API​​进行HTTP调用并直接访问业务对象。（如果我错了，请纠正我）当移动应用程序或桌面或任何人想要访问应用程序时需要API，以便我们可以拥有相同的存储库和数据层。 在我的场景中，我必须创建API，因为我们也拥有移动应用程序，在项目API方面，我们称为业务层（单独的项目），业务层与数据访问层（单独的项目）进行通信。因此，我的问题是，如果我们将API和Web托管在不同的服务器上，那么调用API（这是一个HTTP请求）可能需要更长的时间，而不是在创建项目并且拥有.dll时使用业务层的方法。在API控制器中，我们只是将业务量转换为json格式。 我已经在互联网上进行搜索，但没有得到令人信服的答案。我发现了一个博客http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx，但又讨论了同一点在那个博客中，我的问题是为什么我们需要考虑场景＃3？ 更新：我们可以有不同的API项目和MVC项目，我们可以使用jvascript从Web调用API或使用MVVM模式。
5
如何在Winform中正确构建项目？
不久前，我开始创建一个winform应用程序，当时它很小，因此我没有考虑如何构造项目。 从那时起，我根据需要添加了其他功能，并且项目文件夹越来越大，现在我认为是时候以某种方式构建项目了，但是我不确定什么是正确的方式，因此我没有什么疑问。 如何正确重组项目文件夹？ 目前，我正在考虑这样的事情： 创建表单文件夹 创建实用程序类的文件夹 为仅包含数据的类创建文件夹 添加类时的命名约定是什么？ 我是否还应该重命名类，以便仅通过查看其名称即可识别其功能？例如，重命名所有表单类，以便其名称以Form结尾。还是如果为它们创建了特殊文件夹，这是否没有必要？ 怎么办，以便不是主窗体的所有代码都以Form1.cs结尾 我遇到的另一个问题是，随着我添加的每个功能的主要形式越来越庞大，代码文件（Form1.cs）变得越来越大。例如，我有一个TabControl，每个选项卡都有一堆控件，所有代码最终都保存在Form1.cs中。如何避免这种情况？ 另外，您知道处理这些问题的文章或书籍吗？
5
组织我们的单元测试的最佳方法是什么
这些年来，我们已经为主要程序建立了大量的单元测试。几千。问题在于，由于测试太多，我们没有明确的想法。这是一个问题，因为我们不知道测试的弱点（或重复的地方）。 我们的应用程序是一个报告引擎。因此，您可以有一个模板用于测试解析（我们是否读取了所有表属性），合并数据（是否在合并中保留了正确的表属性），格式化了最终页面（表格是否正确放置在页面上？ ）和/或输出格式（创建的DOCX文件正确）。 除此之外，我们需要测试。在表格单元格周围填充（我们使用Word，Excel和PowerPoint进行报表设计）。我们必须测试跨分页符的填充情况，对于单元格内的表，垂直合并的单元格，水平合并的单元格，垂直和水平合并的单元格（其中包含一个表，内部表中的垂直和水平合并的单元格），该表跨页中断。 那么该测试属于哪一类？表格填充，分页符，嵌套单元格，垂直合并的单元格，水平合并的单元格或其他内容？ 以及我们如何记录这些类别，命名单元测试等？ 更新：许多人建议使用覆盖率工具来验证我们是否具有完整覆盖率。不幸的是，这在我们的案例中用途有限，因为这些错误往往是由于特定的组合所致，因此已经对所有代码进行了测试，但没有进行组合。 例如，昨天有一个客户在其模板（Word文档）的forEach循环的末尾开始了Word书签，并在下一个forEach循环的末尾结束了它。所有这些都使用了针对其进行了单元测试的代码，但是我们没有想到将模板扩展为书签的组合从开始开始25次，然后结束10次（两个forEach循环具有不同的行数）。
3
MVVM，DDD和WPF分层应用程序项目结构指南
我正在尝试在VS中设置我的应用程序的结构，我想“尝试”并在将来对其进行合理的证明。该应用程序将是对旧的Winform应用程序的WPF重写，该应用程序没有遵循任何约定。没有层，层，首字母缩略词等。 这是一个相当大的企业应用程序。我计划将Linq To SQL用作数据库，并且很可能始终是MS SQL。我也有一个现有的技能。 我想尽可能地遵循MVVM和DDD，但是结合使用它们时，我对应用程序的结构感到困惑。让我尝试通过一些示例进行说明。 当我遵循MVVM时，我的文件夹结构可能如下所示： Views Models ViewModels Helpers 但是这如何适合于简单的DDD分层方法，其中我的项目结构可能类似于此： MyApp.UI MyApp.Domain MyApp.Data 我应该将其Models放在“域”层中还是有3种说法Person？这就引出了另一个问题，即我将数据库对象的存储库和映射放在哪里？我会假设数据... Views我会进入UI，但ViewModels也会吗？ 最后，我将业务逻辑嵌入哪里？ 我在CodePlex，DDD示例中发现了以下内容，虽然对您有所帮助，但似乎对Web应用程序有所帮​​助，但这似乎是我的无知。 不要误会我的意思，我知道我可以拥有尽可能多的文件夹，并可以随意命名。我试图弄清楚在哪里放置东西，以便可以扩展，而不是那些地方必须叫什么。 我的问题的核心可能会这样显示。 我有tblPerson产生的物件*.dbml。这很明显，将属于我的“数据”层。 现在，我将拥有Model，DTO，Domain Model或在称为的单独Layer（project？）中调用的任何东西Person。我需要一个Mapper用于Person对tblPerson那个我不知道放在哪里。 然后，我将拥有一个ViewModel，例如，EditPerson它将拥有它自己的属性，Person但可能还会更多。 最后，我将有一个绑定到该ViewModel的View。 需要明确的是，我的假设和猜测已填满该段，我希望有人能为我打气或向他们提供见解，这样从现在开始的6个月到一年内，我不会踢得比自己需要的更多。
2
对Haskell中的GUI库的建议[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 5年前关闭。 正如Haskell Wiki本身所言： Haskell有大量的GUI库。不幸的是，没有标准的标准，而所有标准或多或少都是不完整的。通常，低级别的贴面进展顺利，但级别较低。高级抽象是实验性的。需要受支持的中级GUI库。 我学院的一位教授要求我和其他三个计算机科学专业的学生考虑为Haskell开发GUI库。他对该项目的最初想法是在OpenGL之上编写一个层，该层模仿Smalltalk中的形态库。但是，这只是一个建议，其他系统绝对值得考虑。 这将我们带到一个实际的，包含多个部分的问题。 我们的图书馆应该争取什么抽象水平？Haskell Wiki似乎强烈表明将首选中级GUI库。但是，仍然欢迎使用高级图书馆。 我们的图书馆应基于什么建造？（例如OpenGL） 您希望看到什么现有的GUI库模仿我们的库（如果有），为什么？（例如PyGame，Morphic，Swing等） 您希望我们的库实现或避免哪些功能？例如，Gnome的好人可能会认为“最小化”按钮是不必要的。 您有什么一般性建议吗？ 您会给这个假想库一个聪明的名字吗？（例如HOT-Haskell Opengl Toolkit； HAWT-Haskell Advanced Windowing Toolkit）
6
业务逻辑层（BLL）有什么用？
在学习数据库应用程序的良好实践时，我经常遇到所谓的“业务逻辑层”的拥护者，我试图确定对我的项目来说最好使用一个（这是一个小型的个人项目）。我的问题在于，我无法想到BLL要做DAL无法处理的任何事情（执行查询并将结果映射到对象），所以我的BLL只是在不做任何事情的情况下调用DAL。 也许我对DAL也应该做的事情是错误的。但是，无论如何，数据库管理应用程序中的BLL应该具有什么样的功能？
5
面向架构（结构）与面向特征的项目结构
我参与的该项目具有面向架构的项目的文件/文件夹结构： Root |____ Node1 |____ Event Handlers | |___ <all event handlers of project> |____ Events | |___ <all events of project> |____ Request Handlers | |___ <all request handlers of project> |____ Requests | |___ <all requests of project> |____ ... 从系统的体系结构观点来看，这是显而易见的（已由开发团队提出）。 它是设计人员团队提出的面向功能的结构： Root |____ Feature #1 |____ Event …
4
C项目避免命名冲突
我正在努力寻找有关中型C库项目的函数命名约定的实用建议。我的库项目分为几个模块和带有各自标题的子模块，并且松散地遵循OO风格（所有函数均以某个结构作为第一个参数，而没有全局变量等）。它奠定了我们这样的东西： MyLib - Foo - foo.h - foo_internal.h - some_foo_action.c - another_foo_action.c - Baz - baz.h - some_baz_action.c - Bar - bar.h - bar_internal.h - some_bar_action.c 一般来说，功能远远太大，（例如）棒some_foo_action，并another_foo_action在一个foo.c实现文件，使大多数功能静态的，收工。 在构建库时，我可以处理去除内部（“模块私有”）符号的问题，以避免用户与其客户端程序发生冲突，但是问题是如何在库中命名符号？到目前为止，我一直在做： struct MyLibFoo; void MyLibFooSomeAction(MyLibFoo *foo, ...); struct MyLibBar; void MyLibBarAnAction(MyLibBar *bar, ...); // Submodule struct MyLibFooBaz; void MyLibFooBazAnotherAction(MyLibFooBaz *baz, ...); 但是，我最终得到了疯狂的长符号名（比示例长得多）。如果我没有在名称前添加“假名称空间”，则模块的内部符号名称会发生​​冲突。 注意：我不在乎骆驼案/帕斯卡案等，只是名字本身。
6
大型JavaScript应用程序应该如何构造？
最近向我展示了一些为OBIEE Mobile App Developer编写的JavaScript插件，以及一些用于各种项目的自定义库。 来自OOP的背景，我对这些项目的结构有些困惑。我看到的文件长数千行。我习惯将事物分解为文件和类，但是我知道这是一个不同的框架 -例如，文件大小是一个问题-但是必须有更好的方法来完成所有这些工作吗？ 脚本的长度不仅影响可读性和可维护性，而且还会影响一个人对该程序的工作原理的一般理解。 大型应用程序的结构如何？是否有任何通用的OOP设计模式？
2
分离Java项目
我有一个大型的Java项目，我们在构建周期中使用了maven。这个项目被广泛使用-在其他项目中，在各种应用程序中，其中一些包含在其中，有些则在其他地方...老实说，这有点混乱（针对特定时间，在不同时间添加了不同的位目的），我想对其进行清理。另外，它还没有经过完全测试（没有适当的单元和集成测试就添加了很多位），并且有些测试需要很长时间才能运行或实际上没有通过……（嗯）测试在Maven构建周期中关闭（再次，呃，哦）。 我正在考虑将这个大型项目分成较小的特定项目，以使“最终”子项目（或几个子项目）可以选择所需的各个子项目。 我的想法如下： 如果我将一个大型项目分为多个子项目，这将清楚说明每个项目的责任。 通过分成多个子项目，我可以分别清理每个子项目的测试，然后在maven构建周期中打开该子项目的测试。 我有点担心这可能会对构建时间产生影响。 在大型项目上（即放入较小的子项目中）采用结构会减慢编译器的速度吗？ 另外，我对这可能会对IDE中的编辑时间产生什么影响（我们主要使用Intellij）略有担忧。Intellij似乎是通过依赖关系树依次构建每个项目的-例如，如果C依赖于B依赖于A，而我更改了A，除非A进行编译，否则它不会尝试构建B。可以说这是有好处的，但是我发现，例如，如果我更改了A在B和C中广泛使用的接口，则需要花费一些时间来修复该更改中的所有错误... 另一个问题是如何使用工厂类。该项目的某些方面取决于外部罐子。有时（非常不经常）更新这些内容，因此我们必须进行迁移。我们倾向于使用Factory类来处理此问题，该类指向外部代码的正确版本（因此，我们不必在整个代码库中更改所有实现）。 目前，这一切都在大型项目中，但是我认为通过切换到子项目，我可以开发一个新项目来实施新的外部代码，确保子项目功能完整并经过测试，并且然后在用户项目中切换依赖项/工厂类。但是，由于在整个大型项目中大量使用接口，因此使情况变得更加复杂。例如 子项目A-包含接口 子项目B-取决于A的接口和旧的外部jar 子项目C-依赖于B（以及A和旧的外部jar），并且包含一个使用B的接口实现的Factory类。 如果需要更改B的外部jar，我可以： 创建子项目B_ii-再次取决于A，现在取决于新的外部jar 一旦功能完备，我可以将C的依赖项添加到B_ii，并更改Factory类以使用接口的新实现。 当这一切正常的时候，我就可以删除C对原始B的依赖关系，如果需要，可以删除子项目B。 这是明智的做法吗？ 因此，总的来说，我的问题是： 有没有人有分解大型项目的经验？您是否愿意分享任何提示/技巧？ 这对您的开发和构建时间有什么影响？ 您可以在构建此类项目的分解方面提供什么建议？
1
为iOS应用开发组织代码
我一直在为iOS平台开发应用程序，并且一直在进行中，我注意到我在整理文件（.h，.m，.mm）方面做得很糟糕。在为iOS项目组织文件时，是否有任何行业标准或最佳实践？ 我的文件包括自定义类（在视图控制器旁边），自定义的视图控制器，第三方内容，仅适用于iOS 5.0+的代码以及适用于早期版本的代码。我正在寻找一种解决方案，以一种使其他人（或我自己在未来几年）可以查看并理解应用程序基本结构的方式来组织事物，而不会迷失在其中找到的多个文件中。
4
在托管您的个人废弃项目时，一项服务和项目结构是否突出？[关闭]
关闭。这个问题是题外话。它当前不接受答案。 想改善这个问题吗？ 更新问题，以使它成为软件工程堆栈交换的主题。 4年前关闭。 我正在研究Google Code，SourceForge，BitBucket和GitHub，因为它们似乎是主要参与者。现在，我还没有分解它们提供的所有功能，但是我确实在寻找一个放置我编写的各种代码的地方（我为Euler项目提供的解决方案，可能为Code Golf编写的代码/在一个集中的位置编程拼图堆栈交换等。 因此，我的第一个问题是：在这种情况下，一项服务是否在其他服务中脱颖而出？ 一旦选择了服务，就需要选择如何分发代码。我看到一些用于设置存储库和项目的选项。单个存储库可以容纳任意数量的项目-例如，对于我对Project Euler的所有各种解决方案，我可以拥有一个“ Tom Owens's Project Euler Solutions”存储库，该存储库内目录中的每种语言和环境的项目，另一个存储库适用于我的各种Code Kata解决方案等等。或者我可以按语言细分类似的内容（在一个存储库中有Python的Project Euler解决方案，在另一个存储库中有Java的PE解决方案，在第三个存储库中有Code Kata C ++解决方案）。 我的第二个问题：在确定应如何共享选择的代码示例时，是否存在任何限制或约定，特别是在创建存储库方面？我的想法是，这可能取决于您选择的服务（基于社区的惯例）。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.