Better mood now...
Took a quick walk outside and was able to determine exactly what it was that I wanted to do.
I have both Tony and Veronica as "customers" now. Veronica seems to occasionally run into people that might be interested in software and I would like to be able to rapidly prototype if not rapidly deliver a solution to them as well. And the solution for me delivering on such a thing is one I have talked about numerous times. Which basically a system built up of smaller components. While I was walking outside, it occurred to me where I was going wrong, at least to a degree. My current solution may not be big, but there are things which could, and probably should be broken into smaller pieces. I'm still hashing out how far I should take the process of breaking stuff out, but there is one component which remains the same, and that is the "wrapper" that ties however many components belong in the delivery with the ones specific to a particular industry or business.
So, basically, I split out most, if not all of the model objects and their more generic UI components. These can be reused across projects. In many cases such as with customers, I don't need to recreate something like a Customer grid in every project. I can instead put it into a "core" dll which both projects can reference. Then I can add the grid to each project that needs it with just 2 lines of XAML (one for the namespace and one for the object). It also means that I can upgrade that control and every project using it receives the upgrades.
So, things like a customer and their related components are a no-brainer. The question is how many pieces do I break it into and at which levels.
First thought is take everything out and put it into one unified project for those core items. Makes deployment and integration simple, but could make upgrades frustrating they would become an all or nothing approach.
The other end of the spectrum is completely off my list, and that is a single DLL for each layer and each core object. Don't get me wrong, there are upsides in that updates simply could not be more isolated. If I modified my customer object I could deliver just that one change. The overhead and other implications of that approach are just a nightmare to think on though.
Leaving the final option which is the one I like the most, even though it inherits much of the complexity of the last solution, it makes the most logical sense in a number of aspects. And that solution is to break things out by groups of functionality. Having a separate set of objects and table for things like Work Orders, Inventory, Logging, etc... First advantage is that, inherently, I get a modular database. It becomes easy to draw a line as to where and when to stop my objects from directly referencing one another, and I can then also allow the data access layer to keep more advanced functions in the standard projects such as things like completing a Work Order.
This isn't an easy call. Another hybrid option is to keep the entire data model in a single project and splitting the UI and perhaps even DAL/BLL. Perception I guess is that UI and DAL will evolve more often than the data model, thus my most frequent activities will have a more isolated impact while still retaining the ability to deliver a modular project. The pity here is that I need the DAL/BLL in a project or projects isolated from the UI anyway as I still want the ability to do asynchronous calls to/from a server. Which, means lastly, that probably yet another layer of compromises down is that only the UI components get split. Then I get one project for the data model, one for the DAL, one for the BLL and then separate ones for the UI elements.
Gahhh, I don't any more, before I started typing everything seemed so clear. Now I'm questioning whether I should split the UI elements, or simply isolate those in one project as well, which the specific applications can reference. Still allows me to share the common UI components. Lose all modularity, but are my projects big enough to justify that?
I think the easy answer is that I like changing the underlying framework too frequently to split the anything below the BLL (inclusive) into more than one project. I suppose the DAL could be made modular... though with a unified DB and BLL hard to see the point with the scale of my projects... so decision made I think. 4 separate projects which will be used as the Core.
I have both Tony and Veronica as "customers" now. Veronica seems to occasionally run into people that might be interested in software and I would like to be able to rapidly prototype if not rapidly deliver a solution to them as well. And the solution for me delivering on such a thing is one I have talked about numerous times. Which basically a system built up of smaller components. While I was walking outside, it occurred to me where I was going wrong, at least to a degree. My current solution may not be big, but there are things which could, and probably should be broken into smaller pieces. I'm still hashing out how far I should take the process of breaking stuff out, but there is one component which remains the same, and that is the "wrapper" that ties however many components belong in the delivery with the ones specific to a particular industry or business.
So, basically, I split out most, if not all of the model objects and their more generic UI components. These can be reused across projects. In many cases such as with customers, I don't need to recreate something like a Customer grid in every project. I can instead put it into a "core" dll which both projects can reference. Then I can add the grid to each project that needs it with just 2 lines of XAML (one for the namespace and one for the object). It also means that I can upgrade that control and every project using it receives the upgrades.
So, things like a customer and their related components are a no-brainer. The question is how many pieces do I break it into and at which levels.
First thought is take everything out and put it into one unified project for those core items. Makes deployment and integration simple, but could make upgrades frustrating they would become an all or nothing approach.
The other end of the spectrum is completely off my list, and that is a single DLL for each layer and each core object. Don't get me wrong, there are upsides in that updates simply could not be more isolated. If I modified my customer object I could deliver just that one change. The overhead and other implications of that approach are just a nightmare to think on though.
Leaving the final option which is the one I like the most, even though it inherits much of the complexity of the last solution, it makes the most logical sense in a number of aspects. And that solution is to break things out by groups of functionality. Having a separate set of objects and table for things like Work Orders, Inventory, Logging, etc... First advantage is that, inherently, I get a modular database. It becomes easy to draw a line as to where and when to stop my objects from directly referencing one another, and I can then also allow the data access layer to keep more advanced functions in the standard projects such as things like completing a Work Order.
This isn't an easy call. Another hybrid option is to keep the entire data model in a single project and splitting the UI and perhaps even DAL/BLL. Perception I guess is that UI and DAL will evolve more often than the data model, thus my most frequent activities will have a more isolated impact while still retaining the ability to deliver a modular project. The pity here is that I need the DAL/BLL in a project or projects isolated from the UI anyway as I still want the ability to do asynchronous calls to/from a server. Which, means lastly, that probably yet another layer of compromises down is that only the UI components get split. Then I get one project for the data model, one for the DAL, one for the BLL and then separate ones for the UI elements.
Gahhh, I don't any more, before I started typing everything seemed so clear. Now I'm questioning whether I should split the UI elements, or simply isolate those in one project as well, which the specific applications can reference. Still allows me to share the common UI components. Lose all modularity, but are my projects big enough to justify that?
I think the easy answer is that I like changing the underlying framework too frequently to split the anything below the BLL (inclusive) into more than one project. I suppose the DAL could be made modular... though with a unified DB and BLL hard to see the point with the scale of my projects... so decision made I think. 4 separate projects which will be used as the Core.
Comments
Post a Comment