The essence of the program. 1. Connection to the server, getting a list of current versions of some products 2. Comparison of the received data with those stored in the database 3. Displaying differences

Product class - contains the product id and its name. ProductContent class (list) - product id that owns, disc - content description, href - download link. Versions class (list) - product id that owns, VersionType - version type, Ver - version number .

The layer for working with the database at the moment takes all these classes separately and writes them into the necessary tables. It seems everything looks pretty decent, but the question arose for the convenience of work, these classes need to be combined in some way, the first thing that came to mind would be that the Product class would contain instances of ProductContent and Versions, since this would be convenient for comparing the differences between data from the server and the database data, but then it would be necessary to rewrite the database operation component. The next option was in the component where the data is retrieved from the server and the subsequent verification with the stored data, enter the class, for example, FullProduct and in it already implement ProductContent and Versions + in the same component to register its receipt / saving from the database. Maybe someone came across something similar?

    1 answer 1

    What do you have under the terms: "Database layer"? "Component of working with DB"? What do you really use?

    Try to implement on the basis of EF CodeFirst : create and link your classes with each other, and then compare them with the data warehouse, link to an example :

    public class Category { public string CategoryId { get; set; } public string Name { get; set; } public virtual ICollection<Product> Products { get; set; } } public class Product { public int ProductId { get; set; } public string Name { get; set; } public string CategoryId { get; set; } public virtual Category Category { get; set; } }
    • Architecture laid - a separate project to work with the database. Where prescribed methods for storing and retrieving data from a SQL database. This component operates with the Product, ProductContent, Versions classes separately without linking them to each other. Send to it Product - writes data to the Products table, and so on. In the project where data is being received and their comparison by themselves, these classes are not used, i.e. at this level the product is repr. already as a collection of these classes. The only thing that came to mind was to create AdvancedProduct: Product and already in this class create instances of ProductContent and Versions. - fox06 8:38 pm
    • 2
      What you are describing is the Repository pattern. You can easily make your entity-classes ( Product , Content , ...) on EF (for example, Code First, as suggested above) - this implements for you a link to tables and dependencies, - and write a wrapper on top (actually, Repository) , which will provide the necessary functionality of your module. - VladD
    • Yes, a quick implementation would be with the creation of classes (CodeFirst) - this is the code above + wrapper + one LINQ line to get a set of different values. But the correct implementation in the ready and used solution is to supplement the existing repository with a new method and not to fence a new garden. Or update the code by writing a new repository applying the concept CodeFirst. - michael