Is there any specific way to divide any ASP.NET project between the team members?
I am working in a team and all of us (the team members) are new and each time we have a difficulty with dividing the project between us.
This is somewhat open ended not knowing your environment, skills, type of project, etc. but a 1000 ft view:
Split the application out into separate components. If you are using TFS one user can shelve their pending work so the others can use it and compile OR you agree to code to particular interfaces which you can mock the data on until another team member is done with their component. Since the interface is generally quick to define, you can immediately start using it and generate a stub class to implement it until the work is done.
My team also working on Web Application project. We all are working as
a team using Repository We are using VisualSVN. Using svn, Team
members can use working copy of repository modify their part and commit or update
the changes.For deviding project, some will work on back end
coding(database, stored procedures, webservice etc) and some will work
on front end(Design and coding of master screens etc).. Main thing is
Clear communication between team members(Ex:use Skype), discuss about
project and divide work based on member's expertise and interest
of work.
Related
I am asp.net MVC beginner and I have just created new solution. What I have noticed is that there is now an option of adding two projects under the same solution, and that is something that is new to me.
What is a main purpose that one should add multiple project under same solution?
A solution can hold multiple projects that are related and logically grouped together. For example, a solution may contain two web site projects (a user site and an administration site) and then also a class library project that they both share which contains common database access code or business logic.
Usually we separate our code into multiple projects for easier maintenance in future. On an high level we make separate Class libraries for Data Access, Domain Models, Business Logic. Web project for Front end UI. This way we are physically separating code, that it increases re-usability. Say in future you want to re-use your Data Access components, then build that class library and take the DLL and use it in other projects.
Also in future if you want to replace a certain layer, then you can simply decouple it and change, without changing any other components of code.
This physical segregation of code with Logical Dependency Injection would give you more cleaner, easy to maintain, re-usable, loosely coupled systems
I have a question about a project we are planning to develop.
I will start by describing the project and later I will expose the possible approaches I see to tackle this task. I hope you can give me your opinion on them.
There are 2 main parts:
First part:
In our organization we want to create a kind central access point where users will log in (just one time) and from there they will have links (depending on their roles) to the different services we provide.
Approach:
We are using Active Directory to manage our users, so we thought to create this central access point with SharePoint Foundation.
Do you think that it is a good approach?
Second part:
We have services as a SharePoint were users can share documents, and also other web apps. The idea is to integrate all that in to the previously described central access point.
So far, so good. Now we were asked to develop a new web application. This application will be also part of our services; therefore will be needed to integrate it in the central access point.
Description of the application: It will be an application were 3 different roles of people will fill some information (in an specific order, 1st role will fill in, then the 2nd role, and then the 3rd role). After each step of filling information the next person will be informed by email that his/her part is ready to be filled in. The information to be filled in is an evaluation of a product (just for your information).
The managers of the organization will also want to have a control panel were they can have some statistic over the use of the application. There they can see thing like pending evaluations, evaluation per year, per role, …
Approaches:
As you will see our main doubt are about using
SharePoint Site <--> ASP .NET Pages (C#)
Workflow (SharePoint Workflow or just Workflow Foundation) <--> Using some flags in the internal code to control the workflow
We were thinking to:
1- Giving the idea that we would like to use SharePoint for our “central access point”. We would create the app as a SharePoint web (Using SharePoint Designer 2010 if possible). And apply the SharePoint Workflow to the process.
2- Create an ASP.NET Site and export it as a web part that we can integrate as an application in SharePoint. Try to use somehow the SharePoint Workflow on that. (We actually don’t know well how to do it).
3- Create an ASP .NET Site and forget about the Workflow tools, as our workflow is quite small and sequential, and control all that in the code with some flag.
What do you think about our ideas at the moment? Would you propose us something different?
Thank you very much for your help
Our SharePoint is the free version SharePoint Foundation.
Option 1 sounds the best fit for your approach as long as the web-app isn't aspiring to be something totally outside SharePoint bounds.
As far as basic workflow support goes, the SP Foundations should not be an issue. Refer this article for further details on workflow support in SP Foundations
Options 2 and 3 sound a little adventurous and will involve a lot of custom code which SP will provide you OOTB anyways.
Our company has decided to start using Team Foundation Server 2010 for our development process.
I am having trouble deciding on how to structure our Collections and Team Projects.
We have a total of 9 developers, all working on different projects at different times.
It seems like half of what I read says to use as many collections as you want, while the other half says to limit the number of collections.
What is your approach when creating/managing several projects that don't necessarily interact with each other? Is it best to put stuff in separate collections or is it wise to keep the number of your collections low? Any help is appreciated.
I personally wouldn't muddy the water with a lot of collections here. A default collection with a Team Project for each thing the developers would be working on would be fine.
Each "Default Collection" is kind of like a separate instance of TFS (running within the same environment). The idea is that collections don't cross over each other, and all of the data always stays separate. If I recall correctly (can't test right now because we're still on TFS 2008), you would actually need to switch out of one collection and into another to start working in that collection. I don't believe you can have two collections open simultaneously.
My stock answer for this question is that Team Projects should mirror the lifecycle of you projects. For example, if you have customers and you do projects for customers than I would create a Team Project for each customer project ... Even if it involves the same source code as another project.
For in-house development the lifecycle of a given application is typically "forever" so I'll see them using a Team Project per line-of-business application.
The only reason a shop as small as yours would want to create additional project collections is if you needed that level of isolation. Some reasons include: 1. You have a legal or regulatory reason ro keep source code and work isolated (government, privacy, PCI, etc). 2. You have customers which want their work items and code delivered to them at the end of the project. Some may want the history so it is nice and easy to give them their own project collection instead of having to sort through others' data.
If you need more info, it may help to post what the nature of the projects are.
Each collection requires a separate Build server (and license), so you should consider that in your planning. One Build server, one Collection.
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 am the CTO and sole developer for my company. I'm getting ready to hire our first developer and possibly a second within the next 6-12 months. I'm embarrassed to say that I've never used source code control as part of my workflow. I guess being a 1-member development team has allowed me to be a bit lazy. It's not that I haven't wanted to, I just have a bit of a mental block about how to get started with it.
We have 5 web applications that I build and maintain. We use ASP.NET, and each web app references a single .NET Class Library (DLL) that has been copied into the "bin" folder for each app. I've been developing with a single Visual Studio "solution" that includes the class library and all of the web apps. A bit bloated, I'm sure, but this method has made it easy for me to minimize mistakes by enabling me to do global find and replace operations on all of my apps (and the class library) at the same time.
I realize that implementing source code control is a big change to my workflow by itself, but also introducing another developer into my process has me a bit overwhelmed. I'm looking for some assistance on how to develop a workflow that will enable my small team to move quickly without cumbersome processes. I'd like to avoid discussions about which SCC system to choose (we're going to use Mercurial). I'm more interested in discussing the structure and workflow aspects of this.
Here are the questions I need help with:
Should I split up each app into a separate "project" or keep them all together so we can continue to benefit from global find-and-replace operations when necessary. I'm worried about splitting them up because of the class library situation (see #2).
If splitting up the apps into separate projects, I'm not sure how to proceed with the class library that each project needs a copy of. For example, let's say that the changes to one of the apps (call it "project 1") requires a change to the class library... if the class library is in a separate project (call it "project 2"), it seems "messy" to me that project 1 would be dependent on the latest changes in project 2 in order to work properly. Or, do you simply make your changes to project 2 (the class library), check them in, and then copy the newly compiled dll into project 1 (but shouldn't the new copy of the dll being copied into project 1 be recorded in the SCC somehow). I'm getting confused even as I write this...
Thanks in advance for your help.
First, congratulations on deciding to finally use source control. I know changing your habits can be frustrating but in the long run I'm sure you'll see the benefits.
There's nothing wrong with a solution that has multiple projects in it. I generally keep mine to about 10 but that's simply to improve load times. If keeping them together works better for you, leave it that way. Usage of source control won't have any affect on this.
As far as the class library, I think what you need to do is change the way you go about making changes to the library project rather than how you use the projects that reference it. Implement unit testing on the library project to enforce backward compatibility so you know that dropping the latest version of the library won't break your app. You'll likely find this won't be true a few times but as you develop more unit tests to handle edge cases this will happen less and less.
You can have multiple projects in a single Visual Studio solution. What I've done in the past is to have both the ASP.NET project and the class library project in the same solution. You can have your ASP.NET project reference the class library project (Add Reference and then go to the Projects tab to show other projects in the same solution). That way, whenever you change the class library, the ASP.NET application will be build using the latest version of the class library. You can setup multiple solutions - one for each ASP.NET application with each solution including the class libary project.
You could also setup one large solution with all of your ASP.NET projects as well as your class library but that may get a bit hard to work with, especially with multiple developers working on the different ASP.NET pages.