MVC Implementation Question
-
I've been perusing web documents about dividing up an application into three blocks, the MVC pattern, and it looks like something that would help me to organize a project I've been working on for some time. If I'm understanding what I'm reading, the View portion consists of a collection of user interface elements (forms, in my case) which emit Events in response to user actions. The Model contains all the real functionality, triggered by commands from the Controller, and also emits Events to signal changes in state. The Controller seems to act as a switchboard, monitoring and responding to Events generated by the other two sections, and coordinating everything. That's so perfect for what I need to do that I really want to try it. The question is, and pardon me for being naive, should each of these sections be implemented as separate projects within a solution, or simply as folders within a single project? The default in VS is to simply create everything under one solution, and as the number of classes grows, I find myself easily lost among the many files. Some level of organization is clearly needed, but I don't know which to choose, or what the implications of either choice might be. Although it adds some overhead, I'm leaning toward creating separate projects. My thinking is that, in some similar future project, I may be able to reuse a lot of the structure in the View and Controller elements, though the classes may change. For example, right now I want to read a bunch of text data, parse it, classify the different lines into keepers and fluff, then convert the text of the keepers into records and save them to SQL Server. This is one I've already described, reading electric power meters, saving the hourly values, and later extracting total consumption for user defined time intervals. But next month I may want to do much the same with water well flow rates, chlorine residual levels, and pH readings. It's much the same job, so theoretically I should be able to reuse much of what I've done before. Since my time is so very limited, reuse is a major issue for me. Which approach would you recommend, and why? Will I be creating unforeseen problems for myself if I use the multiple project implementation, or might I actually realize some benefit by creating projects that I can use as starting templates for future designs?
Will Rogers never met me.
-
I've been perusing web documents about dividing up an application into three blocks, the MVC pattern, and it looks like something that would help me to organize a project I've been working on for some time. If I'm understanding what I'm reading, the View portion consists of a collection of user interface elements (forms, in my case) which emit Events in response to user actions. The Model contains all the real functionality, triggered by commands from the Controller, and also emits Events to signal changes in state. The Controller seems to act as a switchboard, monitoring and responding to Events generated by the other two sections, and coordinating everything. That's so perfect for what I need to do that I really want to try it. The question is, and pardon me for being naive, should each of these sections be implemented as separate projects within a solution, or simply as folders within a single project? The default in VS is to simply create everything under one solution, and as the number of classes grows, I find myself easily lost among the many files. Some level of organization is clearly needed, but I don't know which to choose, or what the implications of either choice might be. Although it adds some overhead, I'm leaning toward creating separate projects. My thinking is that, in some similar future project, I may be able to reuse a lot of the structure in the View and Controller elements, though the classes may change. For example, right now I want to read a bunch of text data, parse it, classify the different lines into keepers and fluff, then convert the text of the keepers into records and save them to SQL Server. This is one I've already described, reading electric power meters, saving the hourly values, and later extracting total consumption for user defined time intervals. But next month I may want to do much the same with water well flow rates, chlorine residual levels, and pH readings. It's much the same job, so theoretically I should be able to reuse much of what I've done before. Since my time is so very limited, reuse is a major issue for me. Which approach would you recommend, and why? Will I be creating unforeseen problems for myself if I use the multiple project implementation, or might I actually realize some benefit by creating projects that I can use as starting templates for future designs?
Will Rogers never met me.
I just can tell you about how i have done it (so far at least). Usually i just divide one solution by subfolders for the different layers of the architecture e.g. View, Model, Controller. If for example you look at the ASP.NET MVC approach you'll find this in a similar way. Just by the path of the class file you could tell lets say a View from a Controller. Another benefit is, if you're are consistent in Naming your files you can simply by this convention tell which Control belongs to which View. In my opinion Reuse doesn't come from your project management but the class design itself. Anyway i think it's easier to keep your different layers in one solution. good question btw ;)