<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Sean asked me to outline the 'Model' concept proposed by me and MW and give examples of what classes would move there.<BR>
<BR>
To put it simple, 'Model' as we mean it, is more or less identical to the 'Model' koncept of the MVC pattern<BR>
<BR>
<A href="http://en.wikipedia.org/wiki/Model-view-controller">http://en.wikipedia.org/wiki/Model-view-controller</A><BR>
<BR>
A 'model' is "The <B>domain</B>-specific representation of the information on which the application operates" together with raw data calculations, as calculating current age from birthday et c - and data integrity enforcement, as for example range checks.<BR>
<BR>
The Model does not ACT in the system, but is OBSERVED and ACTED UPON.<BR>
<BR>
Since the model does not act, it never calls on references to (non-trivial) outside types - ie, UserProfile can expose an IUserProfileService (hypothetically a reference to the service that produced it) but it will never CALL on it.<BR>
<BR>
The model assembly should be self-contained in that it should not reference any libraries but the .net System assemblies. This makes it very easy to re-use in other contexts.<BR>
<BR>
While this pattern works best in a SOA or MVC system, just having the model layer brings several benefits:<BR>
<BR>
* Over time, the code starts to move towards better control over state and state-changes (by forcing state-changing behaviour out of the state containers) decoupling and integrity enforcement.<BR>
* The Model can be acted upon by several different contexts, such as<BR>
* Data Serialization (Database, Xml, Remoting)<BR>
* Aux Services (UGAI, Web interfaces, inter-grid logic)<BR>
* Unit and integration Tests<BR>
* Building Tools and Third-party services and applications (that can re-use the model for their inner representation)<BR>
<BR>
Now, since we don't have a fully implemented 'controller' orientation, inheritance has to be side-stepped by formulating the type as interface instead of class. It's less than perfect, but better than nothing.<BR>
<BR>
(For example, currently the SceneObjectGroup is an EntityBase, which means that we would need to inherit the model (data) parts from the model layer and the acting parts (functions) from the business logic layer, which can't be done in a single-inheritance language as c# - so, what we have to do is to at least implement IEntityBase and ISceneObjectGroup, probably supplying classes EntityBaseImpl and SceneObjectGroupImpl for data manipulation purposes only)<BR>
<BR>
We believe this would be a big step forward towards getting the architecture under control and to facilitate third-party extension support.<BR>
<BR>
Best regards,<BR>
Stefan (lbsa71)<BR>
<BR>
** Addendum **<BR>
Some prime candidates for OpenSim.Model (think of what it would mean to have esay access to these types from other contexts, like your own UGAI, Application or Web site)<BR>
<BR>
UUID<BR>
Asset, IAsset<BR>AssetLandmark<BR>
Texture, ITexture<BR>
Wearable, IWearable<BR>
Estate, IEstate<BR>
Region, IRegion (formerly SimpleRegionInfo)<BR>
Scene, IScene<BR>
ScenePresence<BR>
Avatar, IAvatar<BR>
SceneObjectGroup, ISceneObjectGroup<BR>
SceneObjectPart, ISceneObjectPart <BR>
Shape, IShape<BR>
FriendRelation (formerly FriendListItem)<BR>
IInventoryNode<BR>
InventoryFolder<BR>
InventoryItem<BR>
LandData<BR>
UserProfile, IUserProfile (formerly UserProfileData)<BR>
<BR>
IAssetService<BR>
IUserProfileService<BR>
IAvatarService<BR>
IAuthenticationService<BR>
IRegionService<BR>
<BR></body>
</html>