Visual Studio Development Configuration Thoughts
I went through an exercise today that made me very glad I’d set my Visual Studio solution up properly. I had to make some changes to smart forms in my site, changing field types, making multiple fields that were really a “pick one method” and so on. After changing the smart forms, then I had to regenerate the XSD-based classes, and then I had to rework the data code. But because I layered my code nicely, that was as far as I had to go.
I didn’t come up with this idea myself…it’s actually part of an Ektron webinar by Steve Mann. It was supposed to be focused more on dependency injection but at the end, it kind of skimps out (and I’m still hoping for part 2 to really address that!). But in there, Steve describes a good method for setting up your Visual Studio solution. Of course, your project may need something else, but this is a good basic start.
First off, set up a Common class project where you’ll keep code that’s used in all of your other classes. Realistically, this should be devoid of Ektron code, mostly containing things like the smart form XSD-generated classes and your own data classes for translating your data source to your website.
Then, you’ll want to set up a DataAccess class, which obviously is where you do all of your data retrieval (read: Ektron calls). You should reference the Common class here. Basically, this is where you use the Framework API to retrieve data from Ektron, then pass it off to your own classes to return just the fields and data you need. You can also do searches here against the search API, call third-party data sources, and so on.
Next, set up a Business class. This is what connects your DataAccess and your website code. You’ll add references to the Common and DataAccess class projects here. Now a number of your calls here might seem like they’re just pass-throughs (IE, just calling the DataAccess and doing nothing else). But you should also do any custom caching here, as well as combining multiple data calls if necessary into a single product.
Finally, you’ve got your website, whether you’re using the web site project that installs by default or using a web application project that you later combine into a CMS400Min site. This should have references to the Common and Business classes. At this point, you can see that if needed, you could change out your entire data layer and you wouldn’t break your code in the website or business layer. This isolation makes it a lot easier to make adjustments as well.
From there, you can add other helper classes if you want. For example, I have a common functions class that I use from project to project with very generic items, like caching and logging. I also have a common Ektron library that has more generic functions, these routed towards CMS-based items that aren’t specific to my project. For example, I set up a PageBuilderBase class that holds some of the common functions you find in a PageBuilder wireframe, which I can then inherit from in my website, thus minimizing the copy/paste of code. As you develop more projects, you’ll find more of these opportunities to refactor and genericize. as well as what you read other developers put out; I added James Stout’s code to hide unused PageBuilder zones to my PageBuilderBase, for example.
Organizing your project solutions can be a tricky thing, especially if you find yourself unhappy with how you do the initial setup, and it can be really hard to reconfigure once you get into development. I hope this helps you with a starting point at least.