I am looking for an advice on the design decision. I want to create a reusable module(s) include aspx pages. Let’s say I have a huge project which has 10 different modules. When I built the modules all of the modules are built with its own business logic and data access layer. But the UI (.aspx/.ascx) is in one single project. I want to have UI also to be separated and put in the same project related to that module.
Here is the scenario, let’s say, I have created a news feed reader module for twitter, which has
NewsReaderBO – Business Layer (could be in web service)
NewsReaderDAL – Data access Layer
I want to create a NewsReaderUI project where the related UI is placed in such a way it should be easy to plug into other projects.
The advice I am looking for is how the main container project should be designed/organized/architected so that integration of these sub projects is easy.
Are there any references available for this scenario?
The challenge is, over my experience I have worked on various modules now it so happened that when I am creating a new site. I am copying the code from each one, whereby I end up having so many copies of the same thing.
Any advice on this?
Regards
Sai
If you are doing a webforms application you could put each module into it's own library. In the library you could put your code for the module and implement the UI for the module as a server control instead of apspx or ascx, and then use those in pages pages in your main project.
Related
i have just went through this article to create a web application with multiple web application.
https://support.microsoft.com/en-us/help/307467/how-to-create-an-asp-net-application-from-multiple-projects-for-team-d
my requirement exactly match this.i have a large web application which i have to deliver in multiple phases and when deploying the changes of any child project,it should not affect the existing running child project or main project.i should be able to use the use control or dll between the child projects.
i need a sample of this approach. i have tried to create the same but the sharing of user control etc. between the child projects is not working.i think ,i am doing something wrong. if anyone have a sample or example of this approach then please share.
i am working on asp.net web form application not MVC.
Presuming you are using source control effectively, this should not present any problems. You can add a child project at any time and keep it checked out to yourself. When you are satisfied with unit testing you can perform integration testing before putting it live.
The only issue I see with your description of the problem lies with attempting to share User Controls between projects. People have been experiencing problems with this approach for a long time, especially with the Web Site Template. It apparently is possible for Web Forms projects:
How do I share user controls between web applications in ASP.NET?
Creating and Using User Control Libraries
Personally, I think it depends on what you are trying to to with the User Controls. For example, are they just displaying something that is repeated on different pages? In that scenario, make more judicious use of Master Pages. If they are being used for functionality, then consider the creation of a library of Custom Server Controls and reference these in your projects?
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.
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
I was curious how in the typical ASP.NET MVC mentality one could build a platform that others could develop plugins for. I mean, how would those plugins look like?
Like exiting user controls for WebForms, encapsulating all layers in themselves, or three different files representing the model the view and the controller. I should develop the core of a CMS, that I'd like others to build plugins for later on. Which mentality is better for that, classic Web Forms or ASP.NET MVC?
I need developers to be able to separately build components for that. Is it possible to encapsulate the MVC directory structure in a component DLL file and then when I reference the DLL file, to be able to directly access the component's model, view, or controller as part of the general MVC structure?
The most promising component techniques have come from the guys over at lostechies.com and Mvccontrib in the form of Portable Areas. Portable Areas allows an entire MVC app to be appended onto an existing application. So its not just a UI component but also provides all the work flow and screen integration as well.
Open Forum does something like this as well. I don't know how, but it is very plug and play.
For straight up plugin architecture there is an interesting screencast and source code for Rob Connery's link text. He takes advantage of the App-Code directory to slide new plugins into place without having to edit the main site.
I am trying to create a large flex project. This Project consists of a CORE application, and other sub-applications.
The CORE application should contain information that will be shared by all other projects (e.g., link to database, data manager which loads data from the database, application information like height width colors fonts... etc.).
The sub-applications each has a certain task. Each sub-application is a large project by itself so I don't think its a good idea to put all code inside one HUGE project.
The CORE project should run the main application, and through a navigation menu, I should be able to click and run other sub-applications.
Is there a way to created the CORE application to reference those sub-applications so that I can run them inside of the CORE. At the same time, those sub-applications should reference the CORE applications to get the NetConnection to the database and other important information that they might share?
What is the best way to structure this project?
Thanks,
There's two factors to consider.
Where does the code live
Where does the compiled output of that code live.
It likely is a good idea to have all of the source code live in a single code tree. It's way easier to maintain like that. You could put each sub-application in a separate AS3 package.
It's also likely a good idea to separate the compiled output of that code. Make your core application the main flex application, and then make each sub-application a Flex module. The core app can load modules and manipulate them like any other AS3 based class. A great thing about this, is during debug time you can choose to only build the limited set of modules that you care about at the time.
I would highly suggest building your releases through some kind of automated ANT build script and not through Flex Builder.
We have one project that exceeds 150k lines of code that is managed exactly like this. That's not huge in terms of software-engineering, but it's pretty big in the Flex world.
Your best bet would be to put the CORE stuff you're suggesting into a library project. Keep the front end of the application in a Flex Application Project, but all of the data and methods that need to be shared would be easily available to the main application and all of the other modules or applications.
Then in the project settings for your main app and the other applications, you can link to the library project.
If you're planning on using a framework you can also look into the PureMVC Multicore library. It's a bit more complicated than the solution I provided above, but is built specifically to allow the sharing of data and notifications between separate applications.
It sounds like you want to use Flex modules to keep your sub-applications self-contained but still able to interact with the core application.
http://livedocs.adobe.com/flex/3/html/help.html?content=modular_2.html
This will allow you to keep your core application SWF fairly small and load the subapplications on demand.
Typically modules are stored in the same project as the main application but each app / module is compiled into a separate SWF either by Flex Builder or an automated build tool such as Ant or Maven.