I'm trying to implement the OpenEHR reference model in Rails (ActiveRecord), but I'm finding some problems, since it works with a lot of different of different classess,
Here is the diagram of a Composition:
As you can see, a lot of classes "inherit" a couple of attributes from Locatable or Pathable* (the whole reference is huge, and almost every class inherit from it).
Also, it establish data_types as other classes, for example in the same composition class, language is class CODE_PHRASE, that have two attributes (link).
Therefore I encounter two problems 1) how can I inherit attributes from abstract classes, and 2) how is that I can "include" the needed "classes".
For the first problem I thought in using Polymorphic Associations.
For the second one, I thought using STI, but I'm quickly finding a lot of almost similar models (they are exactly the same actually): CompositionLanguage, CompositionTerritory, EntrySetting, EntryEncoding that I only use in the type attribute to "link back", for example: The composition class, can have up to three attributes with CODE_PHRASE, since all three references a different attribute (language, territory and category), I thought that I needed to know for the associations (there's no point in knowing that Composition has 3 code_phrases, but I didn't know which one is the corresponding attribute). On the other hand, the Entry class, have the setting and encoding attribute (link).
I realize that there could be different approaches, but I would really like to know if that maybe Rails (or ActiveRecord), wasn't made for this. Or, maybe I'm missing conceptual info.
The openEHR RM specification has deeply nested inheritance and composite patterns with tree hierarchy.
I could not implement this nested inheritance by ActiveRecord. The following implementation is an example to simulate openEHR RM.
I would be very happy if this example could help you.
https://github.com/skoba/openehr_rm_rails
Have you looked at this project ..
https://github.com/skoba/openehr-rails
I think Shinji uses Active Record.
Personally, given the complex structure of the openEHR RM, if I was starting out I might look to use something like MongoDB with an ORM.
I have pointed the openehr technical community to your question via the openehr technical list to see if others can help.
Ian
Related
So I want to create 3 plugins which include domain classes and a restful service, and who each build on top of each other.
Conceptually, they would "inherit" the base model this way:
Record > Person > User
However I have Read From The Friendly Manual that inheritance may cause some performance issues.
Then it crossed my mind that since Groovy has horizontal reuse capabilities (i.e. traits), I may very well just define everything in the trait and then implement the trait in the domain class.
Composing domain classes is not an option for me because of the renaming of the fields, and well, the loss of the convenience of IDE auto-completion.
My two questions are:
In what part of the Grails project structure would it be best to place these traits.
Can this cause different problems?
The Trait source code should be in
Grails 2: src/groovy/[package][whatever.groovy]
Grails 3: src/main/groovy/[package][whatever.groovy]
For example: src/main/groovy/com/my/package/foo.groovy
The main issue you'll have is that you'll loose the ability to perform polymorphic queries. For example, with inheritance you can do something like this:
def everything = Record.list()
and everything would contain Record, Person, and User instances. Kind of like a SQL union query. When using Traits instead of inheritance you loose this ability.
This is possibly a bit of a stupid question, but I am getting confused due to the ASP.NET MVC book I am currently reading...
Working with Linq-To-SQL it seems to say that it is not good practice to pass the Linq-to-SQL objects straight to the controller, but that each object should be modelled separately first and this should be passed between the controller and the repository.
Say, I have a database of products. Linq-to-SQl creates a product class for me with Name, Price and Whatnotelse properties. I could pass that straight from repository to controller and then view, but instead it seems to recommend that I use and third class, say Product_Entity, with also Name, Price etc. properties and pass that to the controller.
I fail to see the benefit of this approach, except possibly for adding attributes to the properties... But apart from that it seems to have more drawbacks than benefits. Say each product has manufacturer information as well, I don't see how I can model that easily in my third class.
Is this approach really best practice? Or did I misunderstand all that? If so, why is it bad to work straight off the linq-to-sql generated objects? And how do you deal with relationships between objects in y
The huge benefit to this other class you create is that, to use your example, it doesn't necessarily map to either a product or a manufacturer. Think about it like this:
Your Linq to SQL classes are meant for talking in the "data" domain.
Your "data" classes (the ones you're having trouble with) are meant for talking in the "application" domain.
Let's take an example. Suppose in your MVC application you wanted to show a grid of information about products. You want to see their Name, Price (from the Product table) and their Country of Manufacture and Manufacturer name (from the Manufacturer table). What would you name this class? Product_Manufacturer? What if later on you wanted to add properties from yet a third table such as product discounts? Instead of thinking about these objects in purely the data domain, think about them with regard to your application.
So instead of Product_Manufacturer, what about calling it ProductSummaryItem? Each property of the ProductSummaryItem class would map 1:1 with a field shown in your grid on the UI. Your controller would perform the mapping between the information in the data domain (Product, Manufacturer) with the custom class you'd created in the application domain (ProductSummaryItem).
By doing this, you get some awesome benefits:
1) Writing your views becomes really, really simple. All you have to do to display your data is loop through the ProductSummaryItems and wrap them in and tags, and you're done. It also allows for simple aggregation. Say for example you wanted to add a field called ProductsSoldLastYear to your ProductSummaryItem class. You could do that very simply in your views because all it is to them is another property.
2) Since the view is trivial and there's mapping logic in the controller, it becomes much easier to test the controller's output because it's customized to what the view is going to see.
3) Since the ProductSummaryItem class only has the data it needs, your queries can potentially become much faster because they only need to query for the fields that would populate your ProductSummaryItem object, and nothing else. This overhead can become overbearing the more data-domain objects make up your ProductSummaryItem object.
This pattern is called Model View ViewModel (MVVM) and is hugely popular with MVC as well as in frameworks like WPF.
The argument against MVVM is that you have to somewhat reimplement simple classes for CRUD operations. Fair enough, I guess, but you can use a tool like automapper to help out with things like that. I think you'll find fairly quickly, though, that using the MVVM pattern even for CRUD pays dividends, because before you know it, even with simple classes, you'll start wishing you had extra fields which can easily drive your views.
I know I will probably get a mixed opinion on this, but I was wondering if there were and "Best Practices" for model naming conventions.
I have a rather large application and I have adopted the following model naming convention:
Models
Add
CategoryAddModel
ProductAddModel
Edit
CategoryEditModel
ProductEditModel
View
CategoryViewModel
ProductViewModel
I was thinking of the following as well:
Models
Add
AddCategoryModel
AddProductModel
Edit
EditCategoryModel
EditProductModel
View
ViewCategoryModel
ViewProductModel
Which do you prefer, and why?
Do you think it really matters?
I prefer like {ViewName}{Controller}ViewModel. I also remove Models folder, instead I put view models in ViewModels folder. That makes more sense to me.
eg. AddCategoryViewModel
It doesn't matter. You should name things in a consistent, logical, and straightforward way. Basically, just pick something that makes sense and makes you most productive. Consider how your naming convention would work with IntelliSense.
You might also want to consider how easy your code will be to maintain a year from now.
To pull out Hightmaston's comment into a formal answer for clarity.
A logical template to follow would be:
{Controller}{ViewName}ViewModel
This encourages better file organization at scale, and reduces the number of Intellisense "hits".
A simple example might be as follows:
CategoryIndexViewModel
For brevity you may also consider:
CategoryIndexModel
In theory CategoryViewModel, CategoryAddModel and CategoryEditModel will contain the same properties, so there is little point tripling the number of view models you have in your UI. Just CategoryModel should suffice. It's the type of HTTP requests being received by your controller which defines whether it's a GET or POST operation. The model used to populate a view for a GET, or capture form data for a POST will be the same type either way.
This is mostly of a design pattern question. I have one type of model that I'm going to get the data to create them from multiple sources. So for example one record my be created from an API where another is created via screen scraping with Nokogiri.
My issue lies in how best to abstract out these different data sources. Right now I'm building lib classes that return the same hash which I then use to set the attributes of the model. But I'm wondering if this isn't more of a case to use STI. Or if there is some other way of doing this I'm just not thinking about.
I think your design decision would depend largely on what attributes need to be stored. From your description, it sounds like you have a model with multiple data sources, but which would be storing the same attributes regardless of the source. In that case STI seems like overkill. When you retrieve a row from the table, does it matter whether the source is the API or the screen scraper? If not, then you could just define separate methods for each data source and use the appropriate method in the controller.
#instance = MyModel.new(:datasource=>"API")`
I'd say don't worry about inheritance (or mixing in code from modules) unless you really need to. There are some gotchas -- STI is not fully supported by some gems/plugins, for example.
How do most developers handle Typed Views in ASP.NET MVC when dealing with large applications? We are considering putting View-specific models in the Models folder, then putting all domain objects into a separate project. This way our Controllers can easily add the domain object to the typed view, without the domain object needing to be aware of the View layout itself.
For example, if we have an Employee object with:
Id
First Name
Last Name
Status
Then our Employee View might use a ViewEmployeeModel object with:
Employee object
List to populate Status drop-down
etc
Is this a sensible approach? Are there better ways to accomplish the same thing? It seems a little strange since I'd basically have two models (one for the view, one for the business objects), but isn't it better than using untyped views?
I do this almost as a rule, because:
It lets you design the app view-first instead of DB-first, which is nice when working with customer representatives.
Views typically have a much "flatter" object graph than, say, Entity Framework models. LINQ makes it easy to map these.
The views and the data model can evolve much more independently.
It's typically easier to model bind to a flat view model with, say, FK IDs than an entity model which expects fully materialized related objects.
You don't have to worry about accidentally exposing "secret" properties or whitelisting properties for updates.
Don't have the reputation to comment, but Craig is right. It's a variation of the Model-View-ViewModel pattern. There's a good article on it available at Los Techies.
The article also uses the AutoMapper code that mgroves pointed out so you should be able to kill two birds with one stone.
I think this is a pretty sensible approach. One thing that might help you out is AutoMapper.
Seems fine, you have the advantage that the model only contains information needed by the view and not lots of pesky business logic functions / values.