locked
Composite Entity Design Question RRS feed

  • Question

  • I have an issue where I have objects in the domain like Device, Termination, WireTag, WireType, etc. This is with relation to modeling of an engineering design application. These objects provide the information represented by a single database record, let's call this object DeviceWiringRecord. I've been working on an API that uses EntityRepositories, UnitsOfWork, etc.  This process also translates the domain to a DTO/POCO object.  This works great with a one-to-one relationship like DeviceWiringRecord to DeviceWiringRecordDTO with a data-level infrastructure to read/write/update the information.  But as I'm building out the domain, the fact that Device, Termination, WireTag, WireType, etc all provide information represented by the DB record, I really have a many-to-one object relationship.  What's the best way to handle this?  BTW... though this is designed using basic DB principles, the database is actually CAD system drawing files.  So I'm asking the question with regards to patterns and design principles.  Specific technologies like EntityFramework will not work with this though.  Thanks in advance for any assistance! 

    Jason

    Sunday, October 12, 2014 12:24 AM

All replies

  • I'm not keen on database-first for domains, but sometimes you don't have a choice. What's the problem with implementing M:1?

    http://pauliom.wordpress.com

    Monday, October 13, 2014 2:40 PM
  • I assume that what you are referring to is to keep a 1:1 relationship with the record to domain object.  I could, and had initially started down that path, but seems to be limiting in terms of flexibility from the perspective of the client-side of the API.  In other words, if (assuming a perfect world) the domain objects could perfectly correlate to the DB records, then it makes much more sense for the client-side developer to create, read, update, and delete objects like Device, Terminations, WireTag, etc as these are more closely related to objects we're trying to model vs working with an object that correlates less to the model and more to the object record, e.g. the DeviceWiringRecord.  So I'm struggling to figure out the optimal way of doing this.


    Jason

    Tuesday, October 14, 2014 1:10 AM
  • I'm not sure where the 1:1 comment came from but are you asking how to represent M:1 relationship in .net and/or where to create and maintain features such as Unit of Work for a set of entities?

    http://pauliom.wordpress.com

    Tuesday, October 14, 2014 8:44 AM
  • Sorry, I misunderstood what you were asking.  Yes, absolutely.  I would definitely like to know how to represent the M:1 relationship in .NET while maintaining such features as Unit of Work, Repository, etc.  I have to admit, I'm a EE that's self-taught so that I can develop/support our business unit.  I've read a lot of Fowler and Evans material but haven't seen anything along this line.


    Jason

    Tuesday, October 14, 2014 11:12 AM
  • I would recommend taking a look at EF still, and also NHibernate. But I have to question if you really need Unit Of Work? What sort of application are you writing, i.e. where are the objects, in a client app, javascript, on a web server, all of the above, etc.

    http://pauliom.wordpress.com

    Tuesday, October 14, 2014 4:07 PM
  • I'm writing an API that programmatically models an engineering business domain.  In particular, substation design.  The source data is not your typical database.  It's CAD drawing files.  These drawing files do have a database layout, complete with graphical and non-graphical tables.  Interacting with these means using a Transactional approach (Transactional in the sense of the CAD system API).  The records are really objects with certain properties and typically involve using a Transaction to access, then iterate through the entities.  These objects are typically designed around the CAD System, but I'm correlating the CAD object properties to intelligent model properties.  To do this I've created a similar Transactional environment that both familiar to developers used to the CAD API as well as a great fascade to interacting with the drawing files.  I use the UoW to track entities requiring change.  When the Transaction.Commit() is called, the information is translated into their corresponding DTO and communicated to the CAD-level framework where the data is written.  The UoW has been really handy in this respect.  I use a Repository for the reading part.  When entity reads are requested (again through the Transaction.GetObjects() operations) it coordinates communication to the CAD-level framework where the entities of the specified type are read as DTOs, passed to the Repository, cached for later retrieval in an IdentityMap (to prevent constantly hitting the drawing files), translated to the domain-level objects, then passed back to the consumer. 

    If I have one domain object to one CAD entity, this works really well.  In fact, this provides a level of separation that allows me to separate the business from the data and much of the data from the CAD-level interaction.  With this model I'm also able to prevent any intrusion of the specific CAD System API code into the domain.  This has been critical in case we switch systems (which is possible) as well as interact different parts of the domain with different types of CAD Systems (which is also possible).  The problem is when there are more than one domain objects corresponding to one CAD entity.  There are similarities to working with databases, but also some significant differences which have posed some interesting challenges. 


    Jason

    Tuesday, October 14, 2014 4:20 PM
  • One avenue would be to write your own data provider for something like NHibernate, but that might be a step too far...although you either write the whole mapper and identity management (i.e. NHibernate) or you write the data provider so I'm not sure which is worse. As far as coming back to the basic pattern then if you've already written a mapper then you should be able to use something like a Dictionary to implement a M:1

    http://pauliom.wordpress.com

    Wednesday, October 15, 2014 7:36 AM
  • Well, after several hours of board-time and discussions with a teammate, I think what we've identified is maybe some tunnel vision.  The more I've looked at it, the more complicated these object property associations seem to be and neither very straight forward.  Overall I think we were trying to treat all objects of the domain the same when they are really not. 

    What we're looking at doing now is distinguishing these objects as being one of two kinds.  One kind will be an "Entity" and it will be a 1:1 object-to-CAD entity(ies) type relationship.  Then those other objects of the domain we're going to treat as a "ModelObject".  Only Entities will be managed by the UoW, etc, while the ModelObjects will be used independently.  The ModelObjects can also be used to both instantiate an Entity as well as extract any Entities from the drawings based on a Type association to a particular type of Entity.  To do this I'm going to wrap use of the UoW, Repositories, etc, within a Scope object.  Hopefully this separation between domain types will allow the client-side developer to separate modelling concepts from the drawing object management concepts yet provide a toolset to loosely relate the two.  I'll update when completed and let you know how this comes out.  Thanks for your input.


    Jason

    Friday, October 17, 2014 11:30 AM