Vendidi Framework description
Vendidi is a framework able to create database applications on the .NET platform

Vendidi Framework comprises a Class Library and a database structure which a developer can use to speed up the development of .NET applications and dramatically improve productivity.

It's a solution to the requirements of enterprise applications, with a library of ready to use classes, that represent abstractions of objects found in most problem domains, and an infrastructure of basic functionalities, like remoting and O/R mapping.

A developer can just use the available classes, which are highly customizable, or derive from them to build on the existing features and exploit the underlying infrastructure. A web application is included for data setup and management.

Here are some key features of "Vendidi Framework":

· A wide range of concrete classes is available, representing abstractions of objects commonly found within the domain of most Windows and web applications: catalogs, categories, products, parties (persons and organizations), roles, relationships, addresses, languages, currencies , etc.
· Dynamic properties allow to extend existing classes to meet specific requirements, without necessarily deriving from them. A fully comprehensive definition of the type of a dynamic property (data type, range of valid values, default value, etc.) enables effective runtime validation of assigned values.
· The definition of multiple languages and currencies enables the development of fully globalized applications. Multilingual dynamic properties, accepting different values for different languages, can also be defined.
· A customizable O/R mapping infrastructure allows to define the association between a class and a table, a field and a column. Not only value-type fields, but also object-type fields can easily be mapped to a column through a simple attribute.
· Inserting or updating an instance to the database is as simple as calling its Save method (e.g. myProduct.Save()), while the Delete method will be used for its removal.
· Persistency code doesn't interfere with the behavior of the class to be persisted. Each class has an associated mapping interface and delegates any database access operation to an external data mapper, implementing that interface. Alternative mapping interface implementors can be specified through the .config file to replace the default ones.
· Objects are uniquely identified by their Id property. This is a Guid which is also the primary key of database tables where objects are persisted. Each class has a static Get method that uses the Id as an argument to easily retrieve a persisted instance from the database.
· Since an object is persisted along with its type information, it can be retrieved through its Id using the Get method of its most base class: the original derived class instance will be returned.
· DomainObject and PersistedDomainObject, the two base abstract classes from which all classes in the Vendidi Framework Class Library are derived, can be used to derive new custom classes that benefit from all the functionalities of the framework, especially in terms of persistency.
· The Class Library has a complete modularity, with classes representing objects in the problem domain, that, for persistency purposes, use classes taking care of data mapping. These, in turn, use classes performing the actual database access. However, classes of each group are not tied to specific classes of another group, but only to interfaces, whose standard implementation can be easily replaced with different classes specified through the configuration file. This makes the library totally independent from the underlying database.
· Fully remotable classes enable the creation of n-tier applications based on .NET Remoting technology. The number of tiers can be easily varied according to specific software or hardware constraints.
· A catalog contains categories and products organized in a n-level graph, where each entry can have multiple parents and multiple children. These guarantee the utmost freedom when browsing a catalog, using the available methods to retrieve parents, children, ancestors, descendants or to search for entries matching specific criteria.
· An application can have multiple catalogs, with each catalog containing different types of products having their characteristics expressed in one or more languages. Multi-catalog search methods allow to specify criteria to retrieve items from multiple catalogs.
· Custom catalogs can be generated out of subsets of items (categories and products) from one or more of the existing catalogs. This enables to create discounted price lists or to reorganize product presentation for special promotions. Vendidi Class Library contains classes to define rules specifying the items to be included and the policies for their re-pricing, if any is required.
· A product can be a single item or a family of variants, with some features common to the whole family and other specific to single members, including the price.
· A multi-level Bill of Material (BOM) functionality enables to define new products resulting from assembling other products. These packages can be pre-defined or left to customers to define.
· A Party class is the base abstract class for abstractions representing individuals (Person class) and organizations (PartyGroup class) and contains the behavior common to both.
· Classes are available to represent different type of addresses (geographic, telecom, email, website), all derived from an abstract Address class.
· An address can be associated not only to parties, but to instances of any class derived from DomainObject, the most base class in the Vendidi Class Library. For example, a Warehouse class may need an associated address.
· The same address object can be used by the same or different owners, for different purposes (e.g., a geographic address can be a contact address, a shipping address or a billing address, while a telecom address can be a phone, a fax, a pager and so on). DomainObjectAddress, an association class, contains the specific additional information inherent to each context of use.
· Vendidi allows roles to be played not only by parties, but also by any DomainObject derived class instance. The characteristics of a Role instance are defined by an associated RoleType object, specifying its responsibilities and any constraints about which objects are allowed to play that given role.
· Parent/child relationships can be established between roles. Each role may have multiple parents and multiple children and adds the responsibilities of its descendants to its own.
· Relationships can be established between any two objects, playing the same or different roles, using the Relationship class. Vendidi establishes the actual relationship between the two role instances. For example, a Job relationship would be established between an Employee role, played by a person, and an Employer role, played by an organization.
· The characteristics of a Relationship are defined by an associated RelationshipType object, that specifies such constraints, as which roles are allowed to be related, which position a role can occupy (the two roles participating in a relationship are identified as source and target) and how many relationships of the given type are allowed for each role, at the same time and at different times. For example, a job-type relationship must be unique at a given time for the same Employer/Employee pair, but additional job relationship may be allowed for different periods (an Employee may have been fired and, then, hired again).
· Vendidi enables to obtain very complex hierarchies, combining binary relationships as those modeled by the Relationship class, and makes available the methods for a thorough navigation.
· The Vendidi Class Library contains a range of pre-defined relationships, modeling requirements common to most applications, such as contacts (between a contacting person and a contacted organization), organizational units (modeled as a relationship between a parent and a child organization), sales representatives (between a representing person/organization and a represented organization), sales accounts (between a sales representative and a person/organization as a sales lead), employees (in this case modeled as a relationship between an employed person and an employing organization), supply info (a relationship between a supplied product and a supplying organization), manufacturing info (between a manufactured product and a manufacturing organization). Each of these pre-defined relationships are classes derived from the Relationship class, with additional context-related behavior, such as delivery days and price for the SupplyInfo class.


Requirements:

· .NET Framework, MS SQL Server