I just want to know if anyone stores their helper classes or methods in a separate assembly and why...just for clean management of them? I've seen so many posts about using a helper folder inside your MVC project and that brings me back to the messy old days in ASP.NET where people were using an App_code folder instead of cleanly separating things out physically like this into its own project.
And likewise nobody doing real architecture is going to put models in some folder in your MVC web assembly. They would go in MyApp.DataLayer assembly or MyApp.Models or something like this.
Yes, but for reasons, which are common to other assemblies as well
Becomes easy to plug into any other project.(might need some editions).
Reusable
Easy to improve
Easy to refractor
As not part of a project, but project
itself, it is easy to document and easy for developers to understand
Clears out some of the mess
But for all that above, your assembly, when ready, should be a "job well done", other wise, it is better to keep the helper classes to where they belong.
We have some helpers in a separate project and some in the web project. I think you'll find that some of your helpers need to use abstractions that you've defined in your web project itself. And that will often force you to put those helpers into the web project, because it's not likely desirable to have some other project that has a reference to the web project. I don't consider it the same as using App_Code. These are files that are compiled at compile time inside your IDE, with no special "magic" that gets applied to App_Code.
I use projects to separate out the different layers in my web or form apps. It allows me to respect the business rules better. Also I find it easier to track down where I need to go if I want to make a change.
But I have seen people use folders that label the layers in the solution but I think that is a little messy.
Yes, because they are part of the Business Layer. Two big payoffs:
Reusability
Testability
Keep in mind that your utility functions and helper classes are likely to be some of the most heavily used components of your entire system. Without full BICEP testing, you run a truly unacceptable risk.
Most helpers that I create are usually layer specific so I tend to keep them with the assembly the base assembly that needs them. I don't see a reason to add in another project to store a large number of specific helper classes.
Related
When using ASP.NET webforms, I see two main ways to structure a project:
1) Have a lot of .aspx files (including code behind files) and maybe some .ascx files (with code behind files.
2) Rely on a lot of .cs files (class files), and have the classes construct everything with Controls.Add(), etc.
The first method above results in a lot of aspx and ascx files and very few .cs files. The second method above results in a lot of .cs files, but very fewer aspx and ascx files.
Is there a "best practices" way to structure project? Does Microsoft recommend one of these techniques? Is there any information on which of the two styles is used more commonly?
I would stick with the first approach. Some controls are extremely tedious (or difficult) to be created progamatically.
Take the GridView or ListView for example, create an *.aspx page with a GridView which has custom templates with template columns. Then run your application, find the *.dll in the ASP.NET temp directory, decompile the class and look how messy and complicated is the code. It would be very difficult to maintain it over time and/or make changes.
On the other hand, having some declarative code isn't bad as long as you try to maintain the balance.
If you haven't done so, check out ASP.NET MVC. If you cannot opt for MVC you can implement MVP pattern with ASP.NET WebForms. These two patterns provide good way to separate presentation, model and routing.
There is nothing wrong with either approach. Which one you use depends on personal preference, feasibility, and requirements.
One issue you may face is that fewer developers will be able to pick up your project and run with it if you use the second approach, or will take much longer to get up to speed with it. You will find a lot more developers that can easily pick up the first approach and go.
Use approach one as much as possible and only resort to approach two when the out of the box controls do not give you the functionality you require - you can create a custom control by inheriting from an existing control in this case. This is not an "either/or" scenario - you should use both approaches judiciously.
I currently use the App_Code folder for all of my classes, and for me (for now) it seems to be working just fine.
I have however been considering making the switch over to a Class Library Project inside my Solution instead of the App_Code folder. Can anyone tell me the pros and cons of doing this?
One thought I had was with regards to testing my web app. If I use a Class Library, do I have to compile it every time I want to tweak/test? Obviously in the App_Code folder I don't have to since all of the Classes compile at runtime.
You should use a class library. The reasons are simple.
You want to remove your business or application logic from the UI. The App_Code folder is for classes that deal with the UI only.
The reason for the separation is to create tiers. Meaning today you have a web site, tommorow you may be asked to make a windows program, or a new web site. If you have to change your UI you are going to be copying and pasting the code. That means you have now 2 or more places to maintain the code. This will lead to poorer code quality, fixing the same bug in 2 or more places.
If you place your code in a library. You create a new UI and then just reference the library. You are only now using 1 set of code.
Jimmy Bogard (author of Automapper) has written an excellent article on how he structures his code, which may assist in confirming #David's answer.
This may be a broad question because part of the problem is that I actually don’t know what the question is. What I would like to know is how you commonly organise ASP.NET applications in terms of placement of pages (aspx), user controls (ascx), server controls and other support classes and utility functions etc. First, let’s assume that there is already some data layer somewhere (perhaps in a different project). This is the not issue.
The issue I frequently face is that create several pages and realize that they need to share some common rendering logic or some utility function, class etc. Another typical case is that some pages become too large so that it seems handy to split them (say into some user controls). What is the best place to put these utility classes, share classes, user controls, server control etc.? Here are several possibilities.
Don’t really care about any organisation and place all types of files next to each other. So in one directory, you may have an aspx files, some cs files etc. This is not really an option probably.
Organize files by types. Let’s say you create a directory for user controls and put all user controls there. OK, but what about server controls and other regular classes? Should they be in special directories as well? It does not sound right. What I dislike most on this is that when you work on a feature (logically related piece of code), you must hunt it all over the place. I think that features and logical sections of your applications should be also grouped on the file system level in some way.
What I would like to have is to have the pages (aspx), user controls (ascx) and handlers (ashx) basically as dummy placeholders sitting in the directory structure organized from the logically according to the point of view of the outside visitor while the actual code (page, user controls implementations, serve control and utility classes) should be placed in s different folder structured into logical namespaces (organized by the modules or features of the application). It seems to me that the only way to achieve this is to manipulate the <%# Page ... %> directive manually.
Does it sound crazy? Am I asking too much? Is there a better way? What are your best practices? Do you know some good examples?
Edit: Another idea. This does not mess up with the generated aspx, aspx.cs and aspx.designer.cs files. One on my original requirements was that I wanted to place the code driving aspx pages to my own location and put it to a custom namespace hierarchy. So what if I simply subclass the aspx classes generated by VS? Let’s say I have a project called MyApp and MyPage.aspx page in it. VS then creates MyApp.MyPage inherited from System.Web.UI.Page. I leave this class be (no code will go there), but create a subclass, say in MyApp.SomeNamespace.SomeSubNamespace.MyPage, inherited from MyApp.MyPage. This way MyApp.SomeNamespace.SomeSubNamespace.MyPage will get access to the autogenerated protected fields corresponding to the server controls of MyApp.MyPage and I’ll get an entire "private" namespace for all the support classes which are related to this page. Any major disadvantages? Another related problem which bothers me is where should this new cs file be physically placed? In web projects, there is a standard folder for it called App_Code, but I’m interested in web applications. Creating a directory in the root of the application (such as Code) does not sound right.
Remember that you can create page classes that don't actually correspond to any markup. We often create base pages that our actual UI pages inherit from. This is a simple way of organizing "base" page functionality. Then when you create your .aspx pages, make them inherit from the base page class, rather than System.Web.UI.Page.
We usually place our base page .cs files into the top level directory if it's a small project, or for slightly larger projects we'll create a "Shared" or similar directory where they live.
However, we also have a huge enterprise web project, and we simply build our webcontrols and base pages into a class library called CompanyName.Web.UI, with a couple sub-namespaces to that. All our actual web site projects import that assembly and all the code for the controls, etc. is elsewhere. This sounds like it might be a good option for you.
If you remember that your .aspx codebehinds can inherit from any class file, it should make it easier for you to organize.
I want to have a common control library with a whole bunch of User Controls for dealing with common UI scenarios (login etc)
My plan was to have a separate dll for these. But this seems to mean that I lose designer support for them in the referencing application.
Is there any alternative apart from just including a separate copy of each control in the application that makes use of them. This article suggests not
And if I have to include a separate copy. I wonder if there's a clever way to make these controls read only so people can't edit them.
First question: are these web controls or server controls? you'll need to create server controls to do what your looking for.
What you seem to be looking at is to separating your controls to a new project (class library or something similar). Then you can compile and reference it independently wherever you need them, either directly to the project or to the compiled DLL.
You can either include the project in your main solutions, but to keep it read only as you said, you'll need to only provide the DLL to the other projects.
Make sure your controls are set to public, else the designed won't see them.
I have the need to build lots of sites that are very similar, but not exactly the same, using ASP.NET 2.0.
I'm trying to find the best way to make generating these sites quick and easy.
The sites will be used to collect information about a user, and there will be multiple steps for each site.
The sites will all collect similar information, but some sites may require less or more information than others. Additionally, certain form fields will need to be populated from different database tables, based on the site.
I would like to use a Microsoft patterns & practices solution, but I'm not sure that there is one that fits this scenario.
My current thinking is that I will put as much business logic as possible into an external assembly and then write a custom Web user control for each step for each site. I will include these user controls in a master page's Panel control.
I don't like this solution because each site will be nearly duplicating the code for the other sites.
How can I improve upon this design?
The main obstacle is that the sites are similar, but sufficiently different.
Thanks!
Alex
you can create base classes which handle all of the common functionality and then have your site specific controls inherit from their respective base classes and then implement their specific implementations.
We face this problem all the time. What we do is to have a common library that all our sites use, and to bury shared functionality in classes or utility modules in this library. Each site can then use those objects or utility functions as is, or extend the common classes. Keep in mind that these shared classes can include all kinds of things, including code-behind for pages and user controls that you can inherit from and extend.
Deciding what goes in the app and what goes in the common library is one of the hardest things about our business, though. Put it in the common library and you lose flexibility; put it in the app and you risk having duplicate code to maintain.
If you have a fairly complex database setup, it might be worth your time to come up with a framework for specifying your db schema in XML and having your app enforce that schema and build any additional SQL infrastructure that you need based on that definition (e.g. utility views, stored procedures, etc). We did this and it resulted in a huge productivity boost.
Have you looked into Monorail (www.castleproject.org) this is an implementation of themvc pattern, similar to Ruby on rails with a few nice view engines, I prefer Nvelocity.
from castle project as well you can use n implementation of ActiveRecord that makes life real nice. if you are on that trail also have a look at coln ramsay screencasts .
To be honest all ms solutions are real fat
another great thing about the castleproject is that is totally open source so you can learn loads from their code
How about using an Application Framework like DotNetNuke or mojoportal?
They both provide flexibility and enable you to develop websites very quickly with common functionality. Leaving you to develop custom modules where the functionality you require may be different. There are also thousands of other modules that can be bought which provide excellent functionality.
However we chose to use WCSF and enhanced upon it.
All the above mentioned projects are open source and some good examples of code to learn from.
I know it may be a late answer but I hope it helps