对象模型设计选择
我目前正在使用 C# 开发 ASP.NET MVC 报告应用程序。这是对 PHP 应用程序的重新设计，该应用程序最初只是组合在一起，现在开始获得更多关注。因此，我们正在重新设计后端，以采用更加面向对象的方法。我目前正在努力做出的决定之一是如何构建域对象。由于该网站 95% 的内容是只读的，我不确定典型的方法是否实用。
我是否应该为应用程序的主要部分（票据、任务、受让人）创建域对象，然后从这些区域创建静态方法来提取报告数据？或者我应该跳过该部分并创建图表数据类并从这些类中使用一些“获取”方法？这并不是一个很大的应用程序，目前我是唯一一个在它上面开发的应用程序。但我对于采取哪种方法感到左右为难。我认为第一个是更好的选择，但考虑到大多数用途是用于汇总报告，可能有点过分了。
有人对我为什么应该走这种或另一种方式有很好的见解吗？
I am currently working on a ASP.NET MVC reporting application using C#. This is a redesign from a PHP application that was just initially thrown together and is now starting to gain some more traction. So we are in the process of reworking the backend to have a more OO approach. One of the decisions I am currently wrestling with is how to structure the domain objects. Since 95% of the site is read-only I am not sure if the typical approaches are practical.
Should I create domain objects for the primary pieces of the application (ticket, assignment, assignee) and then create static methods off of these areas to pull the reporting data? Or should I just skip that part and create the chart data classes and have some 'get' method off of these classes? It's not a really big application and currently I am the only one developing on it. But I feel torn as to which approach to take. I feel that the first one is the better choice but may be overkill given that the majority of uses is for aggregate reporting.
Does anybody have some good insight on why I should go one way or another?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我采取的方法是首先绘制问题域的概念模型。我的首选方法是对象角色建模，但还有其他方法，例如实体关系建模。
然后我将从这个概念模型中导出我的对象模型。然后，应将问题域定义的行为添加到该模型中的对象中，例如向书店添加一本书，从帐户中提取资金。
其他行为，例如将数据保存在数据库中，最终用户并不单独关心这些行为，应该将其添加到为此目的创建的适当对象中，例如 工作单元 对象，它将形成数据访问层 (DAL)。
在这种情况下，MVC 项目中的模型将包含由 DAL 增强的域对象，并且应该自然地适合创建所需的视图和控制器。
The approach I would take is first to draw a conceptual model of the problem domain. My preferred method is Object Role Modelling but there are others, e.g. entity relationship modelling.
I would then derive my object model from this conceptual model. Behaviours defined by the problem domain should then be added to the objects in this model, e.g. adding a book to a book store, withdrawing money from an account.
Other behaviours, e.g. persisting the data in a database, which, ultimately, the user does not care about in isolation, should be added to appropriate objects created for these purposes, e.g. a unit of work object, which would form a data access layer (DAL).
The model in your MVC project, in this case, would then consist of the domain objects augmented by the DAL and should lend itself naturally to the creation of your required views and controllers.