I use ASP.NET in C#, I am pretty new at developing so I would like have some advice from experts :-).
Questions:
What is the best practice to organizing CLASS FILES?
What kind of name do you use?
For Web Application Project, how do you name NAMESPACE?
In my Case I am building a simple CMS. I thought the FILE structure like this:
- AppCode
- Common
- UserDataInput.cs
- ExternalLibrary
- BusinessLayer
- FrontEnd
- BackEnd
- AccessLayer
Thanks guys for sharing your thoughts with me! Bye
Naming conventions are different for everyone there are no right answers only best practices but there are plenty of wrong ones. When it comes to object oriented programming don't overkill for the sake of modularity some things, like a DataHelpers project which would be be used in your backend could be something you carry around but, say a gravatar helper class (which is an actual class under Microsoft.Web.Helpers) is an overkill simply because String.Format() and a md5 hashing method is all you need for that. It's pretty much eyeballing what you would need again in another project when it comes to modularity.
This goes without saying but, make sure what you name your methods classes make sense in the context that you work, when working with asp.net MVC what I would have a CMS.Controller project and a CMS.View project but all will be under the CMS solution where in classic ASP.net I would have named CMS.BL or CMS.Web. I wouldn't place anything under AppCode just add projects to your solutions and don't call them Common, when carrying your code across solutions they become overcrowded with *.Common namespaces.
So classify your code trough projects in terms of what they are used for and be sure to implement a hierarchy so that your classX that inherits from Xbase is under same sort of hierarchy in temrs of project when you implement this kind of a pattern in your projects you will be more sucsessfull as opposed to Xbase being under CSM.Web.Core and classX under CMS.Web which will later on pave the road to circular references.
Here is an example of a project im working on, it started as a MVC application but later turned into a prject that has winforms and everything.
As long as stuff make sense to you and you are comfortable with, you can get away with everything, like there in the solution below i have a Data.Netsis.Entities that inherits from Entities.Netsis.
Hope this helps.
Related
So I'm trying to get productive practicing TDD in a ASP.NET webpages project, and launching a server every time I want to run my tests, well it isn't quite fast.
So I'm trying to find a way to do my testing without the use of the [HostType("ASP.NET")] attribute, but there is always some error.
We're using App_GlobalResources folder for our resource files, and this is one of the problems; when removing the attributes, just keeping the [TestMethod] (using MStest), it can't find the resources. So I'm !NOTE assuming, that it's not able to find the resources assembly.
So, has anyone done this before? Any experiences?
And comments saying "why don't you just convert to MVC", well it's just to big an app and to little time. Maybe it'll happen in a couple of years, maybe more, maybe never.
My experience testing ASP.NET Web apps has been painful (which looks like yours is too!) Resisting MVC Comment
My best advice would be take little steps each time you touch an area to make it more testable. For example, for any bits of code you can pull out to it's own assembly that you can reference do so.
First candidate would be you resource files. Then your tests could reference that satellite assembly without the "App_" hoops to jump through.
The approach I took involved creating a presenter class for each page. You create an interface that the page implements with methods & properties that the presenter needs to control the UI. All your logic goes in the presenter, along with a reference to the interface. the page references the presenter and passes itself in.
The benefits you get are the page now should only contain code to make the UI work. The presenter does most of the work. Because it can access the UI, via the interface it can control the UI. Because the access is via an interface, you can test the presenter using a mocked UI.
I found my pages were vastly simplified, with much greater differentiation between code to support the logic of the app & code to make the UI work. It also made it simpler to introduce service classes & IoC which is not always the easiest with webforms.
My C# .NET solution files are a mess and I am trying to find a way of getting things in order.
I tried to put all close files together in the same folder I am creating for that purpose. For example, I put interfaces, abstract classes, and all their inherited classes at the same folder. By the way - when I do that, I need to write a "using" statement pointing to that folder so I can use those classes in other files (also a mess I guess).
Is there an elegant way of doing things more clean, and not a list of files that I find very confusing?
Is it a good idea to (let's say) open a abstract class file and add nested classes for all the classes derived from it?
Is there a way of telling the solution to automatically set the folder "using" statements above every class I create?
The best way is when your solution file system structure reflects your program architecture and not your code architecture.
For example: if you define an abstract class and after have entities that implement it: put them into the same "basket" (solution folder) if they make a part of the same software architectual unit.
In this case one by looking on your solution tree can see what is your architecture about (more or less) from very top view.
There are different ways to enforce the architecture vision, understanding and felling of the code file system. For example if you use some known frameworks, like NHibernate, or (say) ASP.NET MVC tend to call the things in the name the technolgy calls them, in this way one who is familiar with that technology can easily find itself in your architecture.
For example WPF force you define in code things in some way, but also you need to define byb the way Model, ModelView, View.. which you will do intuitively in seprate files. The technology enforcce you to define your file system in way it was thought.
By the way the topic you're asking for, is broad known dilema/question, not resolved, cuase the code is just characters sequence and nothing else.
Good luck.
It sounds like you're hitting the point where you actually need to break things up a bit, but you're resisting this because more files seems like more complexity. That's true to a point. But there's also a point where files just become big and unmanageable, which is where you might end up if you try to do nested classes.
Keeping code in different namespaces is actually a good thing--that's the "issue" you're running into with the folders and having to add using statements at the top of your files. Namespacing allows you to logically divide your code, and even occasionally reuse a class name, without stepping on other parts of your code base.
What version of Visual Studio are you using? One little known feature of Visual Studio is that it can automatically create the using directive when you type a class name. That would eliminate one pain point.
If I was in your shoes, I'd start looking for logical places to segment my code into different projects. You can definitely go overboard here as well, but it's pretty common to have:
A "core" project that contains your business logic and business objects.
UI projects for the different user interfaces you build, such as a website or Windows Forms app.
A datalayer project that handles all interactions with the database. Your business logic talks to the datalayer instead of directly to the database, which makes it easier to make changes to your database setup down the road.
As your code base grows, a tool like ReSharper starts to become really important. I work on a code base that has ~1 million lines and 10 or so projects in the solution, and I couldn't live without ReSharper's go-to-file navigation feature. It lets you hit a keyboard shortcut and start typing a file name and just jump to it when it finds a match. It's sort of like using Google to find information instead of trying to bookmark every interesting link you come across. Once I made this mental shift, navigating through the code base became so much easier.
Try using multiple projects in the same solution to bring order. Seperate projects for web, entity, data access, setup, testing, etc.
IF the files are in the same namespace you won't need a using statement. If you're breaking your code into multiple projects you'll need to reference the other projects with using statements.
Its up to you. Break things apart logically. Use subfolders where you deem necessary.
Not sure.
Yes, but you'll need to create a template. Search for tuturorials on that.
1) Your solution folders should match your namespace structure. Visual Studio is set up to work this way and will automatically create a matching namespace. Yes, this requires a using for stuff in the folders but that's what it's for.
So yes, group common stuff together under an appropriate namespace.
2) Yes, subclasses should probably live in the same namespace/folder as their abstract base, or a sub folder of it. I'm not sure if you mean all in the same file? If so I would say generally not unless they're very very simple. Different files, same folder.
3) Not that I'm aware of. If you right click the classname when you use it you can get Studio to automatically resolve it and add a using (Ctrl + . also does this)
I am trying to get a handle on the best practice for code
organization within my project. I have looked around on
the internet for good examples and, so far, I have seen
examples of a web project with one or multiple supporting
class libraries that it references or a web project with
sub-folders that follow its namespace conventions.
Assuming there is no right answer, this is what I currently
have for code organization:
MyProjectWeb
This is my web site. I am referencing my class libraries here.
MyProject.DLL
As the base namespace, I am using this DLL for files that
need to be generally consumable. For example, my class "Enums"
that has all the enumerations in my project lives there. As
does class MyProjectException for all exception handling.
MyProject.IO.DLL
This is a grouping of maybe 20 files that handle file upload and
download (so far).
MyProject.Utilities.DLL
ALl my common classes and methods bunched up together in one
generally consumable DLL. Each class follows a "XHelper" convention
such as "SqlHelper, AuthHelper, SerializationHelper, and so on...
MyProject.Web.DLL
I am using this DLL as the main client interface.
Right now, the majority of class files here are:
1) properties (such as School, Location, Account, Posts)
2) authorization stuff ( such as custom membership, custom role,
& custom profile providers)
My question is simply - does this seem logical?
Also, how do I avoid having to cross reference DLLs from one
project library to the next? For example, MyProject.Web.DLL
uses code from MyProject.Utilities.DLL and MyProject.Utilities.DLL
uses code from MyProject.DLL. Is this solved by clicking on properties and selecting "Dependencies"? I tried that but still don't seem to be accessing the namespaces of
the assembly I have selected. Do I have to reference every
assembly I need for each class library?
Responses appreciated and thanks for your patience.
It is logical in that it proceeds logically from your assumptions. The fact that you are asking the question leads me to believe you might not think it is rational.
In general, things should be broken down along conceptual boundaries rather than technical ones. MyProject.IO.DLL is an example of this principle surfacing in your current design. All of the IO things logically go together, so they end up in a single binary. Makes sense.
Breaking things down into namespaces based on their technical type - enum, class, etc. - is going to be a little more problematic.
The dependencies problem is the same one you'd have breaking one class up with many and it is resolved using the same technique: inversion of dependency. Where two things seemingly need to depend on one another, add an intermediary thing that represents the contract between the first two. This can be abstractions, constants, mediators etc... whatever you need to make it so that instead of thing A depending on thing B and thing B depending on thing A, you have things A and B depending on thing C.
I always run into a problem where my projects in Visual Studio (2008) become huge monstrosities and everything is generally thrown into a Web Application project. I know from checking out some open source stuff that they tend to have multiple projects within a solution, each with their own responsibilities.
Does anyone have any advice for how to refactor this out? What should be in a separate project vs. part of the web project? Can you point me to any reference materials on the subject, or is it just something you become accustomed to with time?
Organize your project cleanly into namespaces. Namespaces should not be too big, not too small. Make each namespace have a public "interface" (i.e. a set of public classes) and don't access internal implementation details of the namespace from other namespaces. Different namespaces usually address different parts of an application, e.g. you'll have namespaces related to UI, business logic, helper functionality, etc. The Framework Design Guidelines have some good suggestions how to design namespaces.
When you feel that your project grows too large, simply identify sets of namespaces that are clearly related to each other and move them to separate projects. Since other namespaces already just use the public interface of the moved namespaces, refactoring the namespaces into new projects is merely a file-move-operation.
Start from the bottom up (your simplest classes that don't depend on anything else besides the Framework) and see if you can isolate the dependencies into functional units. For instance, if you have a bunch of data or business logic classes that reference each other, but never reference any of your UI classes, then you have a candidate for splitting off into another project. If you can't find clear separation points, then you have a design problem and should probably do some refactoring.
I also agree that using namespaces is a good place to start. Even within a project, you can often isolate or minimize dependencies in a way that naturally groups classes together. Putting them in the same folder reinforces this grouping as a functional unit and may really help the poor guy who has to maintain your code in the future. Trust me, I try to think about that poor guy because, on more than one occasion, that poor guy has been me. Twas a small comfort that the person who wrote the code had the same name as me at the time that he wrote it.
Check out the guidance given by the Sharp Architecture project. Its ASP.Net MVC but the same principles apply to ASP.NET and other projects. The guys that put this stuff together are smart I generally use their advice as the default and only stray when I have a good reason.
The basic tiering that they propose is
A core project for your domain objects and interfaces for accessing external services (including persistence).
A data project that depends on core and implements all the interfaces for accessing persistence
An application services project for supporting application-level concerns such as logging or login validation. This only references core.
A web project that holds only views.
A controllers project that holds your bootstrapping code and the code for coordinating your web layer, domain.
In the case of an asp.net app I like to use the mvp pattern which would basically mean the
Web project holds your WebForms and codebehinds which should contain only the minimum amount of code required to redirect to the presenter. You probably also will need to put your bootstrapping code in there. This is due to an ASP.Net limitation and you should NOT reference any of that stuff from your codebehinds.
Controllers project is replaced by a presenters project. The big difference here is that somehow the presenter has to be instantiated by the WebForm rather than the other way around.
You can also try to check out the ASP.NET MVP project.
Wanted to see peoples thoughts on best way to organize directory and project structure on a project / solution for a winforms C# app.
Most people agree its best to seperate view, business logic, data objects, interfaces but wanted to see how different people tackle this. In addition, isolate third party dependencies into implementation projects and then have interface exported projects that consumers reference
View.csproj
BusinessLogic.csproj
Data.csproj
CalculatorService.Exported.csproj (interfaces)
CalculatorService.MyCalcImpl.csproj (one implementation)
CalculatorService.MyCalcImpl2.csproj (another implementation)
Also, in terms of folder structure, what is better nesting:
Interfaces
---IFoo
---IData
Impl
---Foo
---Data
or
Product
---Interfaces/IProduct
---Impl/Product
Foo
---Impl/Foo
---Interfaces/IFoo
All trying to push for decoupled dependencies on abstractions and quick ability to changed implementations.
Thoughts? Best practices?
For me it depends on the model I'm following. If I'm using MVC it would be
Project
-Models
-Controllers
-Views
Or for MVP it would be
Project
-Models
-Presenters
-Views
Under the views I seperate them into namespaces relevant to the controllers, i.e. if I have a controller to handle inventory transactions I might have it as
Project
-Models
--Inventory
-Controllers
--Inventory
---TransactionsController.cs
-Views
--Inventory
---Transactions
----EditTransactionsView.dfm
For interfaces I put the interface in the same directory as the implementations.
Bit of a late answer but may as well chime in.
I have been personally using folders based on the actual type of item it is. For example:
- Project
+ Forms
+ Classes
+ UserControls
+ Resources
+ Data
So I end up with:
new Forms.AboutForm().ShowDialog();
Controls.Add(new Controls.UberTextBox());
We usually keep SourceSafe projects, project names, namespaces and directory structures in sync.
For example, given our company name as XCENT the SourceSafe structure and the corresponding directory structure for App1 looks like:
\XCENT
\XCENT\App1
\XCENT\App1\UI
\XCENT\App1\UI\Test //test harness for UI
\XCENT\App1\Data
\XCENT\App1\Data\Test //test harnesses for Data
etc.
The UI project is named XCENT.App1.UI.cproj, and the classes within that namespace are XCENT.App1.UI
We work for many clients as well so work specifically for them is prefixed with their name. Client1\App1\UI, etc.
Everybody in our firm uses the same conventions and it is immediately clear where everything fits.
If it makes sense to segment logical spacing further we do so. Such other segmentation includes .Export, .Import, .Reporting, .Security, etc.