This site is empty 😉
Nid di ärnst dani?
I’ve been studying your Onion Architecture project. I am struggling with how to implement a project which requires multiple versions of certain objects. Imagine that you have a procedure for creating Widgets. In the middle of creating said widgets, the process department releases a new version of the procedure, however certain widgets that are already in process will continue to use the previous procedure, while any widgets that have not yet been created will use the new procedure. The new version of the procedure might require the addition of fields or it might simply be a different valid range for certain fields. We are using Prism and MEF for the UI if this impacts the direction.
I know I need some sort of metadata mapper or some way perhaps to dynamically instantiate widgets, but I’m unsure of several things, such as
1. should I still use Entity Framework (since only a few of the core domain objects need to be versioned)?
2. should I use a repository pattern for the application.
3. Where in the architecture would the mapping of versioned objects occur?
Any articles or resources you can point me to would be most welcome. Thanks
in advance for your help!
Sounds interessting Without having the “full picture” I can give you some hints. Maybe they can help you. I not quite sure about your questions… but as I said, I have a “isolated view” on this application
1. “Should I still use EF…”: Do you wan’t to use the ADO.NET data readers instead of a ORM like entity framework? Where do you see the problem with EF? I think EF can be very helpful when you are working with base widget classes and child classes. You can decide how you want to store the data in the DB,. (1 table, multiple tables etc.)
–> http://msdn.microsoft.com/en-us/data/ee712907 (Search for TPT inheritance pattern and TPH inheritance pattern)
2. I like the repository pattern. Especially the generic repository pattern. Saves you a lot of work. And you don’t write the LINQ EF queries in business layer.
3. Don’t understand how you will abstract your widgets. But when I read your post, I image that you have a base class for widgets and based on that you create your procedure specific child classes. So with a simple factory (factory pattern) you can decide which widget class you have to instantiate.
Maybe this can help you:
– Version handling with WCF: IExtensibleDataObject: http://msdn.microsoft.com/en-us/library/system.runtime.serialization.iextensibledataobject(v=vs.110).aspx
Correct usage of “Order” in DataMember when working with versions: http://msdn.microsoft.com/en-us/library/system.runtime.serialization.datamemberattribute.order(v=vs.110).aspx
Here is another nice framework (Fluent Validation). It may can help you if you have to define different rules for different versions:
Are you using WF (Windows Workflow)? Because WF would fit nice in your scenario. It supports this process versioning. For example: When you create a new instance of your process (WF) it will run with this version until the end. And if you have a new process definition, new process instances will run on the new process.
But I think at the end, you will always have problems in your database. For example: You have a new required column, or the length of a VARCHAR column changes. At the end of the processes you will store the entities in the DB. But the question is, how do you store the different versions of your entities into the DB structure which maybe supports “only one or two” versions??
Thank you so much for your suggestions; I appreciate your prompt and thoughtful response. I don’t think we’ll encounter a situation where a field length or data type will change. In further discussions with my team it seems that most of the changes historically have been changes to a constant or default value, which would be handled easily enough in a table. Occasionally there could be a change to how a calculation is made, or it might be that Process A–which previously used Procedures X and Y, now uses Procedures X and Z. I believe for now we are going to proceed using Code First entities and a Repository which seems to provide the most flexibility.
Your email address will not be published. Required fields are marked *
+ 1 = five