应用程序架构,实现这一目标的最佳方法
在过去的两到三个月里,我一直在尝试 C# 和 WinForms,但最近我将启动一个项目,该项目将有助于更多地了解在 .NET 中编程时的现实生活问题
。程序员使用 PHP、MySql、Unix 等,当我创建一个网站时,我喜欢有一个具体的框架来处理以下事情:
- 错误处理
- 输入/输出
- 库
- 应用程序结构
- 数据库/模型抽象
- 资源监控
还有一些列入该清单,但我会保持简短。
因此,当我使用 C# 时,我意识到,当应用程序加载时,我们直接运行主窗体,这对我来说,使您在主窗体/中强制执行窗口/窗体的逻辑/就
我个人而言,我可能是错的,这就是应该的方式完成了,但我真的不这么认为,我希望制作一组控制“应用程序进程”的类,这个基本系统将控制表单、线程等的实例化和处理。
所以当 Application .run()
启动我的应用程序,我希望它启动一个名为 System
的对象,然后该对象将解析 设置文件
、注册表项< /code>,
元信息(CPU,Ram等)
,调试器
,开关检测
等。
然后它会处理这些信息并根据影响应用程序负载的不同实体我们将运行一个表单,将信息传递给该表单。
在该表单中,如果 A 用户单击 File > Options
然后它会要求系统加载Options Form,然后System类会加载Options Form并传入所需的信息。
如果该表单需要取消线程,那么它可以作为系统基础,如果它可以将其放置在我的新线程中,并监视它直到完成。
构建一个像这样工作的系统的一个很好的例子是什么,你们对我应该如何去做有什么建议吗?
此外,任何使用 C# 语言构建 MVC 架构的真正好的示例、书籍和文章也将是一个优势。
请赐教我这个问题。
For the last two to three months iv'e been dipping and diving in and out C# and WinForms but recently I will be starting a project that will help be learn more about real life issues when programming in .NET
I'm Mainly a web based programmer working with PHP, MySql, Unix, etc and when I create a website I like to have a concrete framework that would deal with things such as:
- Error Handling
- Input / Output
- Libraries
- Application Structure
- Database / Model abstraction
- Resource monitoring
There's a few more to go in that list but ill keep it short.
So when im in C# I realise that when the application loads we run directly run the main form, which to me, makes you force logic for windows / forms within the Main Form/
Personally I might be wrong, and this is how it should be done, but I really do not think so, I wish to make a set of classes that control the the "Application Process" as such, this base system would control the instantiation and disposing of forms, Threading etc.
So when Application.run()
fires up my application I want it to start an object called System
and this object then would Parse Settings Files
, Registry keys
, Meta Information (CPU,Ram etc)
, Debugger
, Switch Detection
etc.
Then it would process the information and depending on the different entities effecting the application load we would run a form passing information to that form.
Within that form, If the A user clicks File > Options
Then it would Ask the system to load the Options Form, , The System class would then load the Options Form passing in required information.
If that form needs to de thread it would as the System Base if it can place it within a new thread for me, And monitor it until its complete.
What would be a good example of building a system that works like this, and do you guys have any advice on how I should go about it.
Also any really good examples,books,articles of building an MVC architecture within the C# language would also be a plus.
Please enlighten me on this subject.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
罗伯特,
如果您使用 Visual Studio 构建一个新的 Windows 应用程序,您肯定会得到主窗体,如第一个屏幕所示,但它不需要像这样。
Visual Studio 会为您完成此操作。它使用 Main 方法(这是应用程序的入口点,与任何其他语言非常相似)创建一个 Program 类 (Program.cs) 并为您调用主窗体。
查找 Program.cs,您会发现这一点:
知道了这一点,您就可以更改它并执行几乎任何您想要更改应用程序处理表单的方式的操作。
Robert,
if you build a new Windows App using Visual Studio you will definitely get the main form as the first screen shown, but it does not need to be like this.
Visual Studio does this for you. It creates a Program class (Program.cs) with the Main method (which is the entry point for you application, pretty much like any other language) and call the main form for you.
Look for Program.cs and you will find this:
Knowing this you can change it and do pretty much whatever you want to change the way forms are handled by your app.
有不同的架构可以满足这种方法:
分层架构:将应用程序保持在分层中。在单独的层(读取程序集/可执行文件)中实现用户界面(称为表示)。所以应用程序现在已经脱离了winform。将业务逻辑(应用程序流程如何工作)保留在单独的层中,将数据访问保留在单独的层中。
您可以使用 MVC 或自己完成所有事情。通过将这些层保存在 DLL 中并在表示层中实例化它们,将这些层保持在同一进程(进程内)中(与您现在的想法相同)。这样您就可以在业务逻辑层中实现您的类。思维方式是面向服务的架构。在这种情况下,您可以将其余层作为服务运行并使用表示层中的服务。在这种情况下,您可以保留服务器的单个副本。多个前端(表示层)应用程序使用相同的。
There are different architectures to meet such kind of an approach:
Layered architecture: Keep you application in layers. Implement the user interface (called presentation) in a separate layer (read assembly/executable). So the application process is now away from the winform. Keep the business logic (how the application process works) in a separate layer and the data access in a separate layer.
You can use MVC or do everything of your own. And keep the layers in the same process (in-process) by keeping them in DLLs and instantiating them in your presentation layer (the same way you are thinking as of now. So you can implement your classes in the business logic layer. The other way of thinking is the Service oriented architecture. In this case, you can run the rest of the layers as a service and consume the service(s) in the presentation layer. In that case, you can keep a single copy of the server and multiple front-end (presentation layer) application using the same.
如果您正在构建一个更大的应用程序,您可以构建一个框架来处理模块、组件、资源和表单的启动,然后最后显示您的表单。我自己使用 MEF 执行此操作,因此当我的应用程序启动时,我让 MEF 组合所有组件,检索我的来自 MEF 的主窗体,然后使用 Application.Run 启动它。或者我有时会检索主窗体控制器 (MVC) 并告诉控制器处理 Application.Run。
If you are building a larger application you could build a framework to handle startup of modules, components, resources and forms, and then at the end display your form. I do this myself with MEF, so when my applications starts up, I let MEF compose all the components, retrieve my main form from MEF and then start it with Application.Run. Or I've sometimes retrived my main form controller (MVC) and told the controller to handle the Application.Run.