Udostępnij za pośrednictwem

OR Technologies discussion contd

  • Artykuł

What a way to start a blog!!! Got slammed by many people for my cut-throat remarks on futility of current OR technologies. But, I love to have continued discussion on this subject. There is couple of things to start with

a) My remarks are derived from interacting with many customers who tried many different OR implementations and got disillusioned with it. Some of them are due to really ugly implementations of the technology (like J2 CMP) to some of them just didn’t really solve their business scenarios.

b) My research involved looking at *some* OR technologies offered by top vendors and I didn’t really spend time trying to evaluate *all* technologies, which would take very long amount of time. My guess would be that at least 1 out 3 competent app developers have built their own OR technology. Yours truly has built two of them in my former life.

c) I am not against abstraction of relational data. My comments are focused on what should be the right abstraction. The OR technologies of today predominantly use Static types such as classes and attributes that maps to tables/views and columns respectively. This is the abstraction that I was arguing against and I strongly believe a more amorphous data structure such as record sets or XML is probably the right way to go about.

d) I realized that I shouldn’t have used the term ‘Datasets’ as it has lot more baggage associated with it than a simple record set.

Sure enough, some of you may have implemented some thing like Field Collections for more flexible query, as one comment describes it, but I am not sure how this is conceptually different from Record Set. In fact, we are on the same page here.

Also, some of the comments imply that OR fits really well on CRUD like scenarios. Perhaps, you are building such a simple app (I can think of departmental app that has only few users wanting to do few things). Even in this case, I am not sure if OR is helpful as the devs need to go through the training to understand this or that OR technology, where as things such as ADO.NET datasets provide those functionality out of box.

Other arguments are about de-coupling database schema from application developers. I can’t agree with this more. But, it takes a leap of faith to arrive at a conclusion that the OR technologies are the better way to achieve this. I have worked with ERP vendors in the past, and I have seen them taking a different approach (IMO, more elegant approach) to solve this. They do the following

1) Define domain model for the application. Here they define business terms such as Customer ID, LastName, firstname, address etc. On top of that they define entities that maps to business concepts such as Customer, Employee etc. They store this information in a repository (usually called as dictionary).

2) Then they define some attributes for business terms for consistent usage. This may contain information such as syntax, data type etc. Then they finally define storage attributes such as column names that should be used etc. This is not very different from ER modeling.

3) Finally, they map entities to tables/views.

So far, this is not conceptually different from OR meta-data (except that the OR technologies I know have no concept of business terms. They tend to work at the level of entities). Where it is different is that the application developers (like HRMS devs) use queries that uses terms from domain model to get the data from back-end. These queries go through a query layer that translates the business terms and entities to actual fields and tables in the back-end. Again, this query layer is an infrastructure component and app devs are abstracted from translation. The whole point here is that this mechanism allows application developers to define a view of an entity and allows to extract information about that view.

So, what is the advantage of all this? I will give you a simple example. If somebody wants to change a column name for a business term called Customer’s last name from Lname to Lastname, then there is *only one* place in the dictionary that needs to be changed. You don’t have to go and change mapping for every entity. In the OR technologies that I have reviewed, I need to go and change the mapping for all the entities that include this attribute, which is not an optimal way to do this and is error prone. Not that OR meta-data can be extended to do this.

Finally, there is always a question of customization/extensibility. This is especially a big problem for ISVs. Usually customization involves extending the pre-defined entity by adding few more fields, or changing an attribute of a field from mandatory to optional and vice versa. If I use static types such as classes and structs, then it would take huge amount of customization effort to change the structure of these types, add mapping information and deploy them. On the other hand, flexible data structures make it less of a pain (you still have the pain of changing code at all the layers).  This is a huge topic and should be dealt with separately.

Thanks to Paul Laudeman for summarizing my views, though I didn’t express an opinion on interop. I believe that discussion is worth a separate post. J Here is the link to his summary https://dotnetjunkies.com/weblog/plaudeman/archive/12212003.aspx

At the end of the day, I have changed my positions quite a few times in the past. May be it is time to change my opinion now. May be not.

But, I appreciate your critical comments though. As naïve as I may sound, I think I am a good learner J

Comments