Possible patterns and good practices for an sales-administrative app?

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开发者_Go百科 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!

My problem with patterns is that I understand the examples over the internet but I hardly can imagine applying to my model

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:

• your entire domain model (not code)
• your required business scenarios
• your IT topology to support your app
• which pieces of software you need to write
• how each piece of software interacts with other pieces

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:

• Asp.net mvc 2
• Entity Framework
• linq2Sql
• automapper
• viewmodels

Each of these components has a host of patterns naturally built into them. ORM, iterators and MVC are all design patterns, for example.

is it a good practice to write the linq2sql sentences within the models classes

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