如何管理相当大的应用程序开发 [英] How can I manage a quite large application development

问题描述

我正在开发会计软件。这是我正在开发的第一个大型应用程序。因此更关注其维护和未来的更新和版本控制。



我需要使它变得如此灵活，以便将来可以使用新模块轻松更换独立模块，并且不需要再次安装整个应用程序。

例如，

交易凭证部分有5个凭证表格。每张优惠券都有自己的特色。现在，如果将来客户要求在5张优惠券或5张优惠券中提供更加个性化的优惠券，那么我正在寻找一种方式，我只能为他提供相应表格的定制版本。



此外，还有一些需要升级的控件，如DataGridView或ListView。我想在将来创建一个dll并在已安装的位置复制粘贴更新的dll。



如果你能分享你的观点，建议或者经验，那将是很棒的任何外部链接。



我尝试过：



到目前为止，我知道.net和.sln（解决方案）文件中的程序集，如何在单个.net解决方案文件中创建多个项目。



一种方法，我想的是为表格和控件创建单独的Dll文件，并使用应用的接口和抽象来封装类。



其他方法是为每个必需的模块构建单独的项目，并在将来升级这些项目。

I am working on an Accounting software. It is the first big application I am working on. Thus concerned more about its maintenance and future updates and versioning.

I need to make it so flexible such that independent modules can be replaced easily in future with new modules and whole application need not to be installed again.
For e.g.,
There are 5 voucher forms in Transaction Vouchers section. Each voucher has its own characteristics. Now, if in future a customer demands for a more customised voucher among 5 vouchers or all 5 vouchers, then I am looking for a way by which I can only provide him a customised version of the respective form.

Also, there are some controls that would need upgrades such as a DataGridView or a ListView. I am thinking to create a dll and copy paste updated dlls at installed locations in future.

It would be great if you can share your experiences with your views, suggestions or any external links.

What I have tried:

So far, I know about assemblies in .net and .sln (solution) files and how can I create multiple projects in a single .net solution file.

One way, I am thinking is to create individual Dll files for forms and controls with applied Interfaces and Abstraction to encapsulated classes.

Other way is to build individual projects for each of the required modules and upgrade those projects in future.

推荐答案

请参阅我的评论问题。



尽管我仍然认为我的评论是正确的，但我可以帮助你完成一件不需要写完整本书的事情。我可以帮助你消除你似乎对DLL的错觉。尽管将项目分解为较小的项目会非常有帮助，但你肯定会认真对待它。



这就是为什么：模块化的.NET单元不是DLL文件。它们是程序集，它有很大的不同：

公共语言运行时的程序集 [ ^ ]，

了解和使用.NET中的程序集和命名空间 [ ^ ]，

汇编类（System.Reflection） [ ^ ]。



你称之为DLL只不过是一个程序集的可执行模块;通常，每个程序集只有一个，但每个程序集可能只有很少的可执行文件（意思是：PE文件）。 EXE是具有入口点的那个（ Main ）。



DLLs没有.NET中的特殊含义。 DLL，EXE（以及更多）之间的差异并不是真正的基础。告诉你一件不太知名的事情：一个真正的EXE文件（意思是，带有应用程序清单和入口点）也可以被另一个程序集完全引用为DLL。甚至有些情况下它确实具有实际意义。



它如何转化为开发技术？非常简单：组件之间的界限是如此微妙，以至于您并不需要认为应该采取极具响应性的决策。没有类似的东西。恰恰相反：在开发过程中重新考虑程序集之间的代码分配太容易了。使用单个程序集对代码的某些部分进行原型构建并不是不好的做法，随后，随着此代码的成熟，将其部分重新分配到单独的程序集中。此外，它可能会使您的开发过程更加顺畅，因为很难预测代码的哪个部分会变得太大。我告诉你：推迟决定的能力是一件好事。关于在汇编之间分配代码的决定并不是最重要的。



还有更重要的架构问题。您可能对关注点分离的观点过于狭隘。那些更重要的问题包括：如何在线程之间分配工作负载以及如何同步线程（只有一个原则：最佳同步不同步），架构如何反映编程实体之间的依赖关系，以及一个小问题，这是几乎所有架构模式的关注点：UI如何与应用程序的其他方面隔离开来。在更重的情况下，您可能需要应用程序域。而且，应用程序可以分发。无论如何，本段是唯一可以演变为整本书的段落;对于其他问题，一个答案就足够了。



只有一个实用的建议：将所有项目放在一个解决方案中，并在项目之间的程序集之间引用，但是DLL 。通过这种方式，你可以避免很多麻烦。



当你把东西放在不同的集合中时，只有一件事需要有所不同：一些 internal 访问修饰符需要变为 public 。简单，不是吗？



这个答案的主要思想是：这个答案（而不是其他快速答案）不能使用作为大型编程的全面建议。

-SA

Please see my comment to the question.

Even though I still think my comment is correct, I can help you with just one thing which would not require writing a whole book. I can help you to dismiss your illusion which you seem to have about "DLLs". Even though it would be quite helpful to break the project into smaller projects, you certainly take it too serious.

Here is why: the .NET units of modularity are not "DLLs". They are assemblies, and it makes big difference:
Assemblies in the Common Language Runtime[^],
Understanding and Using Assemblies and Namespaces in .NET[^],
Assembly Class (System.Reflection)[^].

What you call "DLL" is nothing but an executable module of an assembly; usually, there is only one per assembly, but it's possible to few executable files (meaning: PE files) per assembly. "EXE" is the one with the entry point ("Main").

"DLLs" have not special meaning in .NET. There differences between DLL, EXE (and a lot more) are not really fundamental. To tell you just one thing which is not very well-known: a "real" EXE file (meaning, with application manifest and entry point) can also be referenced by another assembly exactly as a DLL. There are even the cases when it makes certain practical sense.

How it translates into development technology? Very simply: the boundaries between assemblies are so subtle that you don't really need to think that the decision of what goes in what assembly should be taken extremely responsively. There is nothing like that. Just the opposite: it's too easy to rethink distribution of code between assemblies as you develop. It won't be the bad practice to prototype some part of code using one single assembly, and later, as this code matures, re-distribute its parts into separate assemblies. Moreover, it may make your development process much smoother, because it can be hard to predict what part of code is going to grow too big. I'm telling you: the ability to postpone decision is a great thing. And the decision about distributing code between assembly is not the most important.

There are much more important architectural issues. You probably have too narrow view on the separation of concerns. Those more important issues include: how workload is distributed between threads and how threads are synchronized (just one principle: best synchronization is no synchronization), how your architecture reflect the dependencies between programming entities, and one "little" problem which is the matter of concerns of nearly all architectural patterns: how UI is isolated from other aspects of your application. In more heavy cases, you may need application domain. And also, applications can be distributed. Anyway, the present paragraph is the only one which can be evolved into a whole book; for the rest of the issues, one answer would be enough.

Just one practical advice: put all projects in one solution, and reference between assemblies between projects, but DLLs. This way, you will avoid a lot of troubles.

There is only one thing which needs to be different when you put things apart in different assemblies: some internal access modifiers need to become public. Simple, isn't it?

The main idea of this answer is: this answer (and not other Quick answer) cannot be used as a comprehensive advice for "programming in the large".

—SA

这篇关于如何管理相当大的应用程序开发的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！