I'm working in a web application that has several areas of bussiness work. With time it's size has became a problem to develop on and to maintain.
I would like to break the web project into several sub-projects or libraries depending on a main root web project that has the common files to share (Masterpages, Resources, Css, etc...)
Ideally I would like to have some kind of injection that allows me to optionally publish that "components" or simply publish a customized variation, although it's configuration depended on after deploy DB setup.
I searched all over the web, reading all the pages related to multiple projects, dependency injection and composite apps that I could find, 'till I soften my head, but couldn't find anything really useful.
Major part of the writings where a theoretical approaches or unit testing applications (well, you can't make your desired app, but you still can unit test something else)
Other approaches simply don't work in VS2010 .Net 4.0
Can someone address me on a COMPLETE solution or an example? Or simply lets discuss.
We say that the solution has the following structure, with module contents already separated into directories:
Solution
L_ Datalayer library project
L_ Bussiness logic /common utils library project
L_ Web project
L_ Controls
L_ Images
L_ Css....
L_ Warehouse
L_ Sales
Masterpages
...
Warehouse and Sales contains pages related to the "module"
Thanks,
I post my progress in the subject.
As per suggestion of Steven I experimented further more using MEF. Due to the lack of documentation, specially for webforms, that was a pain in*. So far I managed to implement MEF in my solution and sucessfully inserted a plugin project visible for the main app.
Then loads the available plugins, through an interface that has the plugin name, the default page url and its order, picks all this data and render a menu tab. That part it's easy.
Clicking on a menu element must redirect to the main page of the plugin, which will render several menus for its pages contained (from another export interface)
I finally got an aspx page embedded as a resource in the plugin project. Where I'm currently stuck.
¿Is there any way to render a page embedded as a resorce on a libray using MEF or I'm forced to also use a VirtualPathProvider? ¿Hows specifically the statement to redirect to that page? I've tried several ways but no-one works (MEF and VirtualPathProvider)
I looked at zillion of articles that talk about it but all them end doing control rendering, not page. So frustrating.
Though it is not an answer to your question, I am adding it as answer due to length of my suggestion.
I suggest you look into the approach NopCommerce is following where they have extended over .net with their own framework, which supports Plugins and extensions to existing solutions. Though I definitely know that nopcommerce is an ecommerce solution but if you study it, you can modify it according to your business needs or at least it can give you a heads on for what you should adopt while designing your solution. Hope it helps.
Related
I have an ASP.NET MVC project that is deployed via Visual Studio's Web Deployment - all works fine so far.
I now need to deploy another version of the same project (e.g. for a different customer) - with the same code base/functionality, but with a different layout, i.e. other CSS and images (maybe even with different views/Razor code). Ideally, the content from the other configuration would not be published at all.
I know I can use different connection strings for the persistence layer - but is there a way to configure also configure other content elements?
I'd like to avoid having two versions (or later even more) that required branching/merging - but rather like to simply deploy the latest version with the different "themes"...
I have a MVC project with 4 class libraries. And i deployed it into 3 other domains.
I copied only MVC project without controllers or code classes for each client, and added them into my solution. I use them only for visual changes or themes. Not for server side functionality. So the copied projects' assemblies shouldn't be deployed. Only the UI files should be deployed. Assemblies are deployed from the original MVC project's output folder.
I build solution and publish dll's into 3 domain, and publish only each client's UI files into it's server.
This enables me to develop server-side functionality in only one MVC project. Separate UI files from server side functionality.
Hope this helps.
are you using MVC then?
What you can do is to override the default razor engine and create your own. What the razor engine does is mainly to map your requests to views in particular folders, you can tell the razor engine when to map those requests to views in one folder or another.
MVC4 Razor Custom View Locator
A full fledged explaination is here :
http://nickberardi.com/creating-your-first-mvc-viewengine/
That is for views, if you just want the CSS or JS to be different, you just have to map your requests to a razor bundle and then vary what the content of the bundle is depending on a variable, or the pressence of a configuration file, or by filling a variable with a value from the database.
As you can see here bundling is very easy :
http://www.asp.net/mvc/tutorials/mvc-4/bundling-and-minification
Say your html points to : /assets/mycssbundle.css , but what that file would actually contain can be altered by where you tell to the bundling function that the files are located.
This seems like a design question. If you foresee possible changes like this in the future, and you already swap content via DB, then you should consider loading css file from database. There're of course many other ways to do this but simple and efficient is preferable.
This would mean structuring your html properly to ensure all layout is properly handled via CSS and can be achieved via ViewData or ViewBag. See case example.
Edit:
Not css data but the relevant css file.
You have two options:
A) Develop a custom view engine that switches between different page sets depending on the configuration. This will allow you to switch between the page sets just by changing the web.config settings, which fits well with the visual studio's built in deployment model (different web.config transformations kick-in for different deployment environments). One implementation that comes to mind - switch between view engines for different deployment environments (in different web.config transformations).
Unlike the other suggestion to load pages from the DB, I would recommend loading them from folder or physical location (e.g. different view engines targeting different sub-folders of the project). DB approach is not developer friendly when it comes to developing and fixing pages and their markups that are in the DB.
B) Develop all page sets (all variations) under the same project and then write custom deployment scripts which deploy particular page sets depending on the deployment environment. Drawback of this approach is that it's hard to notice issues like page sets intersecting or links crossing the page set boundaries.
While plan B sounds a little bit simpler development-wise, it can become a nightmare maintenance- and deployment-wise.
So, I recommend plan A.
Your Question is too broad.
However we have also a similar use case. We put all the theme related stuff (css, images, etc) as an embedded ressource in a separate assembly. We have Customer1.Theme.dll and Customer2.Theme.dll etc.
The App loads dynamically the Theme.dll and references the ressrouces from there.
Among other solutions,
assuming that you are using asp.net mvc.
and assuming that you have content1 and content2 folder available in the same repository or making available in same repository is not a concern.
and assuming your are bundling your contents.
and assuming your images are referenced only using css.
You can have a app config key which will tell you whether you want content1 or content2.
something like,
<add key="sitecontent" value="content1"/>
Now in your Application start in global asax, read the app config key and depending on the value, call the
BundleConfig.RegisterContent1Bundles(BundleTable.Bundles);
BundleConfig.RegisterContent2Bundles(BundleTable.Bundles);
I think this is a design issue. As you can see below you can organize your .net application in different layers:
Source: Microsoft
There are some key principles (Separation of concerns, DRY, etc) that Microsoft strongly encourages through the .net platform and I believe will find good use in your project.
Based on what you describe a simple approach is to keep in one project -same for all clients- your business layer (including the Services or the Data layer - even with different connection strings for each project) and create separate projects for the Presentation layer.
You may find more information from Scott, CodeProject, or more traditional methods (BTW this is a great book).
*This is more of an architecture level question.
I am new to DNN development , we are trying to build an e-commerce site which will showcase all the products which will be tied to our current order database.
Am I wrong in assuming that any custom development that I do via DNN would be in MODULE form ? I created few custom module (i.e. list of products) which would tie to database in code behind and display data from SQL. This seems to be very heavy approach if I have to make modules for every functionality.
Is there a better way here ? Can I (is it recommended) to directly change the DNN pages to accommodate this type of functionality ?
UPDATED
Is it possible to do development without moduels ? i.e. provide code right in the html text editor or something. If i create new module from DNN template then it adds many files ....that is why it feels heavy
It is strongly recommended that you not directly change DNN. This will make it very difficult to apply upgrades to DNN and cause headaches for whoever maintains the site after you.
The main extensibility point in DotNetNuke is the module. The module is just some executable controls that you can place on any page. It shouldn't be significantly heavier than any other approach you would take. Whatever you want to do in DNN itself, you should be able to do in a module, and just place the module on a page.
You could also potentially have some of your functionality in the skin, rather than the module, if that is easier or makes more sense. Generally, the skin has functionality that is shared across most pages in the site, and module are used to place specific content on specific pages.
If you're looking for something simpler, you might try using the core reports module, which will allow you to style the results of a query from the database (if you don't need the interactivity that a module would provide).
Your good options are as follows
Build a separate Web Application for your e-commerce, but provide heavy inter-linking with the DNN site. With this method, DNN would be used for content.
Purchase a third party e-commerce module-set like SmithCart and try to configure it to meet your business model
Build custom DNN modules
Our current project utilizes option #3. We have 25,000 products and about 3,000 product listings with heavy customer-customization functionality.
While it might seem heavy, as in, a distinct module project per section of e-commerce, it doesn't have to be too complex.
Example Modules:
Product Listing
Product Details
Shopping Cart
Order Checkout (we split this into 4 modules)
Search Module
Search Results Module
You can use URLRewrites to map all your products to the same DNN Page/Module.
As a result, we really have very few non-content DNN pages.
In summary, it might feel a bit heavy, but with the proper design it can go rather smoothly in comparison to a separate web app.
There are ways to use existing DNN features without module development. You can do it by adding a sub application in your folder.
For example, you can look at http://www.firstphera.com/GiftRegistry/Index.aspx, FirstPhera.com is a main dnn application and folder GiftRegistry is a pure asp.net sub application that uses dnn's providers to deal with database. Custom implementation of registration and login was the only thing that was challenge, everything else working fine.
But If are building an e-commerce application, at long term you will get benefit from module development way.
It is not strictly necessary that you create separate complected module like you shown in screen shot. If you look at blog module, it has feature like latest blogs, search blog, archives etc are all implemented in single module.
It is also possible to create a single module with related features in dotnetnuke using the technique called ModuleDefinitions. Look http://lakhlaniprashant.blogspot.com/2010/04/dotnetnuke-what-is-module-definition.html.
I would strongly recommend to visit NBStore source code if you want to understand the e-commerce related module development in detail.
Please let know if you have any other question.
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
1.The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
You can do this with DNN. They're also called "modules" in DNN and Drupal.
2.Each Module should have their own DLL's.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control
We have a series of ASP.Net applications that have been written over the course of 8 years. Mostly in the first 3-4 years. They have been running quite well with little maintenance, but new functionality is being requested and we are running into IDE and platform issues. The apps were written in .Net 1.x and 2.x and run in separate spaces but are presented as a single suite of applications which use a common navigation toolbar (implemented as a user control). Every time we want to add something to a menu in the nav we have to modify it in all the apps which is a pain. Also, the various versions of Crystal reports and that we used tables to organize the visual elements and we end up with a mess, especially with all the multi-platform .Net versions running. We need to streamline the suite of apps and make it easier to add on new apps without a hassle. We also need to bring all these apps under one .Net platform and IDE.
In addition, there is a WordPress blog styled to match the style of the application suite "integrated" into the UI and a link to a MediaWiki Wiki application as well.
My current thinking is to use an open source content management system (CMS) like Joomla (PHP based unfortunately, but it works well) as the user interface framework for style templating and menu management. Joomla's article management would allow us to migrate the Wiki content into articles which could be published without interfering with the .Net apps. Then essentially use an IFrame within an "article" to "host" the .Net application, then...
Upgrade the .Net apps to VS2010, strip out all the common header/footer controls and migrate the styles to use the style sheets used in the CMS.
As I write this, I certainly realize this is a lot of work and there are optimization issues which this may cause as well as using IFrames seems a bit like cheating and I've read about issues with IFrames.
I know that we could use .Net application styling, but it seems like a lot more work (not sure really). Also, the use of a CMS to handle the blog and wiki also seems appealing, unless there is a .Net CMS out there that can handle all of these requirements.
Given this information, I am looking to know if I am totally going in the wrong direction? We tried to use open source and integrate it over time, but not this has become hard to maintain. Am I not aware of some technology out there that will meet our requirements? Did we do this right and should we just focus on getting the .Net streamlined? I understand that no matter what we do, it's going to be a lot of work. The communities considerable experience would be helpful. Thanks!!
PS - A complete rewrite is not an option.
Hmm, we're in the midst of a project to do something that sounds familiar. We're using www.sitecore.net CMS but you could use the Open Source alternative Umbraco again both of these will have a learning curve, but they're .Net apps and aren't targetted specifically at blogs. SiteCore ultimately can use normal .Net user controls if you want, though it's slightly against their model, but it works.
One thing I'll warn you of is SiteCore Must be the root of your website, it has to control the root of the domain (it has a urlrewriting module that needs to be at the root) and you can tell it to exclude certain folders where your applications might live. You can obviously put your navigation in a folder under the root of the site. Also note SiteCore's a .Net 3.5 application running under the 2.0 runtime.
Are your sub-applications.. Actual seperate applications in virtual dirs or something I'm guessing?
Depending on the nature of the .Net apps, you may find DotNetNuke to be a useful choice.
It's a CMS where you write widgets ('modules') in .Net, then add them to the pages of the CMS. In your case, you'd wrap your existing functionality in such widgets. I've done exactly this several times, and now that I'm used to it it's no big deal.
The downside is you have to learn to swim in the DNN environment, which (like any CMS) has a bit of a learning curve.
I'd have to know a lot more about your existing apps to be sure this is a plausible option. If it looks appealing, you should probably contact someone who's dealt with a situation like yours (such as myself) and go into detail. It's very easy to find yourself in a dead end with these CMS frameworks.
Edit: Like a product mentioned in a different answer, DNN has to control the top level of its subdomain -- all requests begin by going through Default.aspx and are then dispatched in various ways.
One of the projects I was in charge of as a JSP/Struts developer at my last employer was a themes tag library (present on every WebSphere server as a shared library) that let any Java web dev in the company pull in any of the standard themes like intranet, public, etc. with minimal effort. The themes included header, footer, navigation, and links to css & javascript, etc. They could even customize things a bit when we gave them the option, like choosing a selected tab.
This setup was ideal because we could make centralized change to any standard UI elements and they were automatically pulled in by all sites using themes without any effort by the site developer.
With the new job I started in December, I've switched to using ASP.NET. I'd like to propose something similar in spirit to the themes app here, since we're running a bunch of different sites that should have a unified look and feel.
What's the best way to accomplish this? I'd rather not have to recompile anything to update the theme to make this work.
Edit:
Although I was hoping for a better answer, the .NET gods apparently don't approve of what I was trying to accomplish. Here are the three options that were found:
Compile a Master Page into a DLL and put it into the GAC:
This works in simple cases, but as a hack it's too brittle. I couldn't get it to work correctly with our site.
Create a virtual directory to the Master Page in each web app: This actually does work, although it doesn't make for a very comfortable development environment. However, one of the things we are trying to move away from is having to create virtual directories inside each web application. No dice.
Create a bunch of custom controls, compile them into a DLL, and put it into the GAC: This is the answer I selected. It's the least centralized option and requires more work for the developer of each site, but it seems to be the only Microsoft-blessed way.
In conclusion, I'm pretty frustrated with .NET over this. In the grand scheme of things Master pages are just code, and I don't see any reason why they couldn't be easily centralized for use in multiple web applications. This seems to be a major loss compared to JSP/Java.
You can put some UI into the form of custom controls or server controls (if not in MVC) and then place them in the GAC thereby distributing them. All references to the controls in that assembly will be pulled from the latest version in the gac. You can also do things via the Machine.config which is controlled at the server level rather than the app level.