销售管理应用程序的可能模式和良好实践？
在我的 asp.net mvc 2 应用程序中，我有以下规范： 我必须制作一个广泛使用 JQuery 的 POS 系统（所以我对这部分的模式不感兴趣），并在我的模型中生成按时间段分类的销售和销售报告。 我还需要向产品提供商生成订单。 我有销售、产品、销售报告、采购订单和产品提供商等实体。
我将使用 Entity Framework、linq2Sql、automapper 和 viewmodels 将信息传递到 aspx 页面。
我对模式的问题是我理解互联网上的示例，但我几乎无法想象将其应用到我的模型中。 您认为有什么常见的模式可以应用于这种情况吗？也许有一些使用任何模式的“类似”示例？
另一方面，在模型类中编写 linq2sql 句子是一个好习惯吗？ 例如，执行以下操作来获取 Models/Sales.cs 中的销售列表是否正确？
public List<Sales> GetSales(DateTime Date1, DateTime Date2){
var sales = from item in data.Sales
where ((item.Date> Date1) && (item.Date< Date2)) &
select item;
//Rest of code
.......
}
提前致谢！
In my asp.net mvc 2 application I have the following specifications:
I have to make a POS system that extensively use JQuery (so I'm not interested in patterns in this part) and generate sales and sales reports classified in periods of time so in my model.
Also I need to generate orders to products providers.
I have entities such as sales, products, sales reports, purchase orders and products providers.
I will use Entity Framework, linq2Sql, automapper and viewmodels to pass information to aspx pages.
My problem with patterns is that I understand the examples over the internet but I hardly can imagine applying to my model.
Do you think in any common pattern which can be applied to this scenario? Maybe some "similar" example using any pattern?
On the other hand, is it a good practice to write the linq2sql sentences within the models classes?
For example, is it right to do the following to get the list of sales within Models/Sales.cs ?
public List<Sales> GetSales(DateTime Date1, DateTime Date2){
var sales = from item in data.Sales
where ((item.Date> Date1) && (item.Date< Date2)) &
select item;
//Rest of code
.......
}
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
尝试将低级设计模式适应您所描述的高级概念根本行不通。为了开始编写低级软件，您必须解决这些高级问题：
一旦建立良好，您就可以开始处理诸如单个应用程序的高级架构、实现业务需求和交互所需的相应类以及协作之类的事情这些班级将彼此相处。
低级设计模式确实适用于最后的部分 - 各个类或类系列之间的协作。
当然，您始终可以尝试自下而上的方法，并在设计固化之前开始编写代码。但是，只有当您知道将使用哪些类以及它们需要如何交互时，您才能够应用模式。
换句话说，我必须查看您的代码才能告诉您应该使用哪些低级设计模式。
您的描述详细信息表明您已经在使用更高级别的模式：
这些组件中的每一个都自然内置了许多模式。例如，ORM、迭代器和 MVC 都是设计模式。
如果您只从常见实践中获取示例，那么您可能会避免它。由于某种原因，人们似乎喜欢多层应用程序中的普通旧对象。
然而，一些专家认为这种使用无代码域（模型）对象的极其常见的做法是一种反模式：请参阅 http://en.wikipedia.org/wiki/Anemic_Domain_Model 和 http:// /www.martinfowler.com/bliki/AnemicDomainModel.html
Trying to fit low-level design patterns to a high-level concept like you have described simply won't work. In order to even start writing low-level software, you have to have these high-level concerns ironed out:
Once that is well established, you can start working on things like your high-level architecture for your individual application, the corresponding classes that will be required to implement your business requirements and interactions, and the collaborations those classes will have with each other.
Low-level design patterns really apply to this final piece - collaborations between individual classes, or families of classes.
Of course, you can always try the bottom-up approach and start writing code before your design is solidified. But you're only going to be able to apply patterns once you already know which classes you'll be using, and how they need to interact.
In other words, I'd have to look at your code to tell you which low-level design patterns you should be using.
The details of your description show that you are already using higher-level patterns:
Each of these components has a host of patterns naturally built into them. ORM, iterators and MVC are all design patterns, for example.
If you only take your examples from common practice, then you probably would avoid it. People seem to like plain-old-objects in multi-tiered applications for some reason.
However, some experts consider this extremely common practice of having code-less domain (model) objects to be an Anti-Pattern: See http://en.wikipedia.org/wiki/Anemic_Domain_Model and http://www.martinfowler.com/bliki/AnemicDomainModel.html