Advice on Architecture for customized application
-
Hi to all, This post is to claim for your wisdom and experience, I’m developing an application that provides certain standard functionalities: inventory management, orders, invoices, accounts receivable, etc. (I’ll call them core functionality) The problem here is that features solves the 90% of my customers requirements, BUT always need to make some customizations in order to fit each customer policies and special processes. So, the main challenge here is to design an architecture that allows me to make customer specific changes (most of the time they affect the database structure adding fields and/or tables, changing their corresponding UI’s for entering or viewing these new fields, adding validations, etc) without duplicating the core functionality, so if I made a fix or enhancement to the core functionality I’ll be able to distribute the changes to all my customers. I hope I explained it clear, I already tried many alternatives but none likes me at all, hope any one can help me, I’m sure most of all ever have an scenario like this, when the customers says “all is great BUT it needs just some “little” changes to fit me 100%”. At this time I’m at design stage, so I’m wide open to fresh ideas. Thanks in advance, regards
-
Hi to all, This post is to claim for your wisdom and experience, I’m developing an application that provides certain standard functionalities: inventory management, orders, invoices, accounts receivable, etc. (I’ll call them core functionality) The problem here is that features solves the 90% of my customers requirements, BUT always need to make some customizations in order to fit each customer policies and special processes. So, the main challenge here is to design an architecture that allows me to make customer specific changes (most of the time they affect the database structure adding fields and/or tables, changing their corresponding UI’s for entering or viewing these new fields, adding validations, etc) without duplicating the core functionality, so if I made a fix or enhancement to the core functionality I’ll be able to distribute the changes to all my customers. I hope I explained it clear, I already tried many alternatives but none likes me at all, hope any one can help me, I’m sure most of all ever have an scenario like this, when the customers says “all is great BUT it needs just some “little” changes to fit me 100%”. At this time I’m at design stage, so I’m wide open to fresh ideas. Thanks in advance, regards
And here lies some of the worst and best designs ever inflicted on the user community (to say nothing of the poor bastards supporting the application) In most cases I use an Item/Attribute structure as Product/Size Attribute/Measurement Attribute. This is all very well until you require discreet processing for a particular attribute type. You are getting to the core of the OO design philosophies and you need a book no a library to cover the subject. trying to find a "correct/best" design is like picking the best beer or the correct indexing strategy. Hopefully it will stimulate an interesting thread (or be completely ignored)
Never underestimate the power of human stupidity RAH
-
And here lies some of the worst and best designs ever inflicted on the user community (to say nothing of the poor bastards supporting the application) In most cases I use an Item/Attribute structure as Product/Size Attribute/Measurement Attribute. This is all very well until you require discreet processing for a particular attribute type. You are getting to the core of the OO design philosophies and you need a book no a library to cover the subject. trying to find a "correct/best" design is like picking the best beer or the correct indexing strategy. Hopefully it will stimulate an interesting thread (or be completely ignored)
Never underestimate the power of human stupidity RAH
You're right, OO is supossed to solve these common challenges, and in theory it does, the problem comes when trying to get it into practice in a really complex system. Until now I solved using not OO techniques but tricks to parametrize the code, so I have all my customers speciall code in the same source and it's enabled or disabled at run-time. I know it's not an elegant or OO way, but it's the only way to reduce a little the maintenance. What I'm looking for in this thread is to get some ones experience and different ideas to find an better OOper and elegant solution, hope that could happen Regards
-
Hi to all, This post is to claim for your wisdom and experience, I’m developing an application that provides certain standard functionalities: inventory management, orders, invoices, accounts receivable, etc. (I’ll call them core functionality) The problem here is that features solves the 90% of my customers requirements, BUT always need to make some customizations in order to fit each customer policies and special processes. So, the main challenge here is to design an architecture that allows me to make customer specific changes (most of the time they affect the database structure adding fields and/or tables, changing their corresponding UI’s for entering or viewing these new fields, adding validations, etc) without duplicating the core functionality, so if I made a fix or enhancement to the core functionality I’ll be able to distribute the changes to all my customers. I hope I explained it clear, I already tried many alternatives but none likes me at all, hope any one can help me, I’m sure most of all ever have an scenario like this, when the customers says “all is great BUT it needs just some “little” changes to fit me 100%”. At this time I’m at design stage, so I’m wide open to fresh ideas. Thanks in advance, regards
For an application like this OO concepts will only take you so far. Effectively what you are looking at building is an extensible framework that allows third-party customizations without the need to change code. Systems like this can be built but they are not trivial. You need to start at the framework level and build your core framework in a very well structured way. Even though your core components are related to one another, I would build them as separate pieces as much as possible and provide the hooks necessary for them to interoperate. You also want to make sure that you have a robust data layer. One approach that I have used in the past is to build things up in layers. I had a data layer that understood XML (and XML only). The data layer had the responsibility of parsing that XML and inserting data into the database and also taking data out of the database and putting it back into XML. My business objects were effectively specialized dictionaries. The flexibility in the user interface is also going to be a challenge, although if you can guarantee that certain elements will always be there (and in the same layout) you can take advantage of the visual inheritance capabilities offered through Visual Studio. (This is nothing more than regular inheritance where your base class is a visually designable "thing" (like a form or user control). As long as that base class is not abstract you can visually design the derived class in VS just like you normally would.) As for distribution of changes/fixes, you need to make sure everything is built in a very modular fashion (separate DLLs or assemblies for each component). That will allow you to update specific portions as needed. If you want to go beyond this and actually implement a system that allows for this without code changes you need a lot more work and design as it will require publishing type services to update the database, which will also require conflict resolution to ensure that you don't remove user-made customizations with an update. From there the problem gets more complex as your business objects must be written in such a way as to be able to expose an unknown number of properties and metadata. The UI then needs to know how to render those objects in a completely dynamic fashion, with rules that govern how that layout works in the face of an unknown number of properties. All of that is possible, but definately not trivial.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be m
-
For an application like this OO concepts will only take you so far. Effectively what you are looking at building is an extensible framework that allows third-party customizations without the need to change code. Systems like this can be built but they are not trivial. You need to start at the framework level and build your core framework in a very well structured way. Even though your core components are related to one another, I would build them as separate pieces as much as possible and provide the hooks necessary for them to interoperate. You also want to make sure that you have a robust data layer. One approach that I have used in the past is to build things up in layers. I had a data layer that understood XML (and XML only). The data layer had the responsibility of parsing that XML and inserting data into the database and also taking data out of the database and putting it back into XML. My business objects were effectively specialized dictionaries. The flexibility in the user interface is also going to be a challenge, although if you can guarantee that certain elements will always be there (and in the same layout) you can take advantage of the visual inheritance capabilities offered through Visual Studio. (This is nothing more than regular inheritance where your base class is a visually designable "thing" (like a form or user control). As long as that base class is not abstract you can visually design the derived class in VS just like you normally would.) As for distribution of changes/fixes, you need to make sure everything is built in a very modular fashion (separate DLLs or assemblies for each component). That will allow you to update specific portions as needed. If you want to go beyond this and actually implement a system that allows for this without code changes you need a lot more work and design as it will require publishing type services to update the database, which will also require conflict resolution to ensure that you don't remove user-made customizations with an update. From there the problem gets more complex as your business objects must be written in such a way as to be able to expose an unknown number of properties and metadata. The UI then needs to know how to render those objects in a completely dynamic fashion, with rules that govern how that layout works in the face of an unknown number of properties. All of that is possible, but definately not trivial.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be m
Hi Scott, Thank you for your explanation, I think that's exactly what I'm looking for. But now I realize the challenges for creating an extensible framework, are much more than creating the core functionallity. The core should be aware of the possiblity to be extended, and also my business layer should be totally decoupled. I'm wondering I'll need to create a lot of interfaces or abstract classes to allow the interoperabilty between the different objects. In my system there is a lot of interaction between classes, they're tight coupled and I should separate them. I guess I should create a prototype or look for some extisting model in order to evaluate if the effort in design and decoupling the objects worths it or if I should stay with my current model. Thank you for your ideas! Best Regards
-
Hi Scott, Thank you for your explanation, I think that's exactly what I'm looking for. But now I realize the challenges for creating an extensible framework, are much more than creating the core functionallity. The core should be aware of the possiblity to be extended, and also my business layer should be totally decoupled. I'm wondering I'll need to create a lot of interfaces or abstract classes to allow the interoperabilty between the different objects. In my system there is a lot of interaction between classes, they're tight coupled and I should separate them. I guess I should create a prototype or look for some extisting model in order to evaluate if the effort in design and decoupling the objects worths it or if I should stay with my current model. Thank you for your ideas! Best Regards
ruben ruvalcaba wrote:
think that's exactly what I'm looking for. But now I realize the challenges for creating an extensible framework, are much more than creating the core functionallity.
You're welcome. Yes, creating systems like this is possible but not simple. (I'm involved in building one at work now and it's been a very long road and a lot of work involved.)
ruben ruvalcaba wrote:
I'm wondering I'll need to create a lot of interfaces or abstract classes to allow the interoperabilty between the different objects
We are doing things with a combination of interfaces, abstract classes, and generics from the framework layers.
ruben ruvalcaba wrote:
In my system there is a lot of interaction between classes, they're tight coupled and I should separate them.
You should look at doing this no matter what. The more tightly coupled your objects are the harder they become to maintain. Generally you want a loosely coupled but highly cohesive system. (http://en.wikipedia.org/wiki/Coupling_(computer_science)[^]). In the long run, making sure you have a solid and well-thought-out architecture is always worth it as it leads to code that is more easily maintained and extended in the future. It all depends on where you want to spend your time/effort/money - up front in the design or afterwards in the maintenance phase.
Scott. —In just two days, tomorrow will be yesterday. —Hey, hey, hey. Don't be mean. We don't have to be mean because, remember, no matter where you go, there you are. - Buckaroo Banzai
[Forum Guidelines] [Articles] [Blog]