You might not like these kinds of questions, but I rely on the professionalism of StackOverFlow.
I have a very big ASP.NET web application, it contains many projects, a container (father) project, and multiple module projects. Obviously it's connected to a big SQL Server database as well.
This application doesn't have a specific documentation.
Is there a way (special tools, advices...) that would help me in understanding the functionality of the application gradually?
I meant by special tools, those that might be representing the structure of the system in diagrams or so.
I cannot find a way to start with.
Note: I'm using Visual Studio 2010, the application is built using .NET 3.5
Thank you for your opinions.
Personally, I usually prefer to start by looking at the database design. Depending on how it was set up, you should be able to create a database diagram which will show you all of the relationships between the tables.
Once you have a grasp of the database design, you should have a basic understanding of what the system is doing, which should give some context to the different processes and work flows throughout the web application.
If the application has a Sitemap, I would examine it throughly, as it should help you to better understand the flow of the application. If available, you should also look at the class diagram to see how the different classes relate to one another.
Without any kind of documentation, you'll probably have to use bits and pieces to understand how the application works. I'm not sure, but there may be some plugins available that can help you with this. Something like CodeRush or Resharper might be helpful. There's also a plugin called GhostDoc that might come in handy too.
Hope this helps.
Visual studio 2010 has architectural analysis it can perform on your projects with the ultimate version. This can help you in understand the app, what crosses layers, etc.
See:
http://msdn.microsoft.com/en-us/gg465276
http://www.slideshare.net/bgervin/visual-studio-2010-ultimate-architecture-experience-toronto-code-camp-2010-barry-gervin
You can have a look at this MSDN page, which will show you how to generate a UML diagram from your codebase. This will give you a rough overview of how things fit together, and what communicates with what (I haven't used this tool so I'm unsure of how much information is provided, or whether it is configurable).
Also, make sure you ask your teammates, or anybody else who has worked on this application before (there have to be a few such people around if it's such a huge project). They should definitely make the time to explain things to you, or at least answer specific questions you have.
Related
I'm a little confused about new Microsoft products.
I'm a classic webform Asp.Net developer. I know exists also Asp.Net MVC with a different approach based on Mvc pattern.
Now, i know exists also WebMatrix that uses new Razor "notation".
Can someone explain me what are the main difference between that "technology" ? When use WebMatrix, when WebForm ?
Thanks!
Webmatrix is a platform that integrates a variety of recently released technologies such as IIS Express, Asp.Net Webforms, Razor, SQL Express etc. I guess from what I have been reading it's a way that eases the barrier to entry, for non-MS developers, into the MS world. In addition you can also use code your site in PHP and use a variety of open source tools for developing web sites. To directly answer your question, in you planning on creating a complex web application, WebMatrix may not be the solution you're looking for.
As a reference, I suggest reading through Scott Gu's Introduction to Webmatrix
WebMatrix will be able to take
advantage of these technologies to
facilitate a simplified web
development workload that is useful
beyond professional development
scenarios – and which enables even
more developers to be able to learn
and take advantage of ASP.NET for a
wider variety of scenarios on the web.
If you are a professional developer
who has spent years with .NET you will
likely look at the below steps and
think – this scenario is so basic -
you need to understand so much more
than just this to build a “real”
application. What about encapsulated
business logic, data access layers,
ORMs, etc? Well, if you are building
a critical business application that
you want to be maintainable for years
then you do need to understand and
think about these scenarios.
Imagine, though, that you are trying
to teach a friend or one of your
children how to build their first
simple application – and they are new
to programming. Variables,
if-statements, loops, and plain old
HTML are still concepts they are
likely grappling with. Classes and
objects are concepts they haven’t even
heard of yet. Helping them get a
scenario like below up and running
quickly (without requiring them to
master lots of new concepts and steps)
will make it much more likely that
they’ll be successful – and hopefully
cause them to want to continue to
learn more.
One of the things we are trying to-do
with WebMatrix is reach an audience
who might eventually be able to be
advanced VS/.NET developers – but who
find the first learning step today too
daunting, and who struggle to get
started.
If someone is still interested: a pretty good lessons here http://habrahabr.ru/company/microsoft/blog/136004/ . This link is for those, who understand russian.
Shortly speaking WebMatrix allows you to conveniently mix up C# server code and html (this mixing is provided by simple Razor sytax). Also in WbeMatrix 2.0(beta version now) is provided full IntelliSense for html/css/c# code.
I've been trying to learn how develop websites with ASP.NET as well as setup a personal website to use as a online porfolio/resume. With my website I've decided to not try to reinvent the wheel and thus decided to use a premade ASP.NET based CMS.
After reading a lot of reviews I settled on Umbraco, but now I'm seeking out alternatives. I like Umbraco a lot but I keep running into problems. Since installing it on my host I haven't made any changes through the file system, or database directly. All changes have been through the admin site. Yet somehow I kept getting it into some state where I could not delete a datatype, and now I'm having problems removing or renaming one of my templates. I've searched for Umbraco forums for solutions and usually find that I have to run some SQL script workaround on the database to clean things up. This kind of thing is really not something I want to fiddle with for my personal site.
Has anyone else had a lot of problems with Umbraco like I have? Are there other free CMS systems out there that are more reliable, yet similar to Umbraco? Specifically I really like how Umbraco gives me total control over the HTML generated by my site. Simple is also better in this case. I'm not trying to create some kind social network/community portal/forum/blog site. There won't be multiple people logging onto this site or anything like that.
I've been reading a bit about N2, which I'm now starting to consider. I like that it's more developer based and that you setup page types through real .NET classes in Visual Studio. Again I don't want to attempt to build my own CMS from scratch, but at the same time I really don't like how hard it is to see what's going on under the hood with most other CMS systems.
I haven't used N2 so I can't comment on that, but alternatives you can consider are Orchard or FunnelWeb, both are on MVC 3 and Razor.
If you're wanting a blog that is mostly just a blog then FunnelWeb is a good option.
I'm currently writing a comparison between Orchard and Umbraco if you're interested as well.
I think you'll be happy you stuck with Umbraco. I was so frustrated with Umbraco when I first started working with it for the exact reasons you stated above. The issue with not being able to delete data types could mean that it's connected to something (IE: document or media type) somewhere and if you force delete it (IE: via the db) you could really mess up your install. <- speaking from experience.
I'm absolutely in love with Umbraco now though. I am completely confident that I can build just about anything I need with it now.
I think that my best piece of advice I can pull from my own experience is make sure that you've got your site architecture planned out thoroughly before starting to build it out in Umbraco. You don't want to be fiddling around in there afterward changing things and that's where you can really get yourself into some hot water.
Have fun!
if you want a minimal .net mvc4 cms with good performance check out puck https://bitbucket.org/yohsii/puck/overview
it adds very few concepts on top of what you need to know for .net mvc but it does require .net4.5 (and therefore VS2012) to work with.
it also uses localdb out of the box but if you don't want to install that just attach the database mdf file to regular sql server and change the connection string
Recently I ran into this open source project ASP.NET WebformsMVP.
It seems like an alternative to asp.net mvc and also a quick way to introduce testability into an existing webforms applications. (without having to go through the pain of rewriting a bunch of code to make it work for asp.net mvc)
Of couse community support and open-source projects abandonment is always a concern when trying new things, but moving on from those fears, has anyone giving it a serious try at this framework? If so, can you share some insight into its pros/cons and if it's really worth trying it?
Thanks a lot!
WebformsMVP is included in DotNetNuke now, so we have started using it indirectly as part of custom module development within DNN.
I don't think we're fully utilizing everything the framework is capable of, but have had no problems to date. The implementation is very clean and simple to implement, and retrofitting existing webforms code is fairly straightforward. For us the learning curve has been minimal.
We have run into a number of cases where we aren't certain of the "right" way to do things, and have found pretty limited guidance online. (Try as I might to avoid it, sometimes I just have to poke some stuff into the ViewState.) But, with it being used by the DNN team, we feel pretty confident that it will not fade away soon, and a growing number of examples should appear online.
Of course I encourage its use, even if only for the selfish reason of wanting to see the community grow.
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
For our company I'm creating a big Extranet website which will feature a set of sub-applications. I'm a bit puzzled by what should be the right setup of the solution and projects.
I have one web application that we call the Portal. It contains the authentication/authorization classes, masterpages, navigation/url routing classes and theme definitions. It will also contain some basic overviews for our customers to get a quick idea of their project status.
In the coming year we are going to develop and integrate more applications with the portal. Think of it as detailed overviews and tools called Feature A, B and C. Over the years we will improve these applications and release new versions. These web applications should fit into the navigation of the Portal seamlessly. I'd like them to reuse the masterpages and themes.
What is the proper way to setup this solution?
How can I tie the applications together, re-use the master pages and keep it maintainable?
How can I share certain webcontrols (ASCX) in a proper way?
We are using TFS, perhaps any branching/merging ideas?
Edit:
I'd like to create it in ASP.Net WebForms, we have the most experience in that area. But basically we can use anything, we've got the webserver under our own control (as long as it is Microsoft oriented, not switching to php or something like that :))
What is the proper way to setup this solution?
The proper way... There are so many. I have seen a lot of applications, and a lot of different setups (a lot of which that I would deem "proper"). What you're really asking is for the best way for your situation.
Because you're building a portal, you'll have the luxury of feature separation which will help you as you develop additional features for your application.
I would setup a single website with a separate folder for each feature. Making it a single website will allow all features to share the same masterpages, usercontrols, and configuration file - without having to do anything special. (On that note, I would put all your master pages in a folder by themselves, and create another folder for your usercontrols).
How can I tie the applications together, re-use the master pages and keep it maintainable?
Again... folders are the best option here. Folders will help separate each feature, making the application easy to manage.
How can I share certain webcontrols (ASCX) in a proper way?
First of all, ascx files are not webcontrols. They are usercontrols. WebControl is a class for creating server controls that reside in a separate assembly. Regarding usercontrols, as I said above, if you put them in a separate folder, they're always in one place and available throughout the application.
We are using TFS, perhaps any branching/merging ideas?
There really isn't anything special you need to do here. There are a lot of different paths you can take regarding branching:
One is to create a branch for every release.
Another is to create a branch for every new feature you add (in your case, this is pretty much the same as the first option).
Yet another is to create a branch for each developer.
When I decide how I am going to branch my code, I think about what will protect me the most. In your case, you need to plan for bug fixes in between feature releases so maybe one branch after each release makes the most sense (call it your dev branch). Given the separation of features, though, one feature may not effect the rest of the application. You may not need this kind of branching to be safe.
As Brian says when making an API public you should commit to it as much as possible, which means it should change as little as possible after the initial release. However to make something that stable requires lots of effort up front so if you aren't ready to commit to the API you should instead internalize it as much as possible and for that reason you might want to combine things more than separating them.
However, I'm not going to suggest an architecture that fits your application based on a 5 paragraph description. What you need to do is to weight pros and cons of having a few big projects vs. having a bunch of loosely coupled small projects. I mean, the more planning you do up front, the easier you will have it down the line, provided you stick with the plan.
So contrary to Brians answer, I wouldn't recommend you make your entire system "as loosly coupled as possible", only that you make it as loosly coupled as it needs to be. ;) Loosely coupled code can cause as much trouble as tightly coupled code, if you are abusing it.
See:
1. What is better, many small assemblies, or one big assembly?
2. Specific down-sides to many-‘small’-assemblies?
In the end, only you know how much you want to focus on each of the "...bilities", maintainability, extensibility, reliability etc. So get your priorities and goals straight and plan accordingly.
Regarding branching strategies you could read the TFS Branching Guideline 2.0 which have a good introduction to various branching strategies ranging from basic to advanced. Even if you don't use TFS this is a good guide to read (I use SVN at the moment). Since I currently work in small teams with 1-4 devs, I tend to use a strategy that is between basic and standard. Not that I'm recommending this for you, but that whats works best for our team.
As for sharing code between projects. In SVN we can use "externals" which means that the shared file will appear in several folders so when you change one copy and commit the change to svn, all the other copies will be updated on the next svn update. However, I can't remember if TFS have something similar.
Note: Beware of externals in SVN... they can cause... problems. ;)
My advice is to try to avoid sharing aspx, ascx and master pages as much as possible. It usually hurts a lot more than it helps. Instead try to use inheritance or other alternatives to achieve your goal.
ASP.NET MVC 2.0 has a concept called "Areas" where you build subsections of an application in isolation from the rest. As far as I know these areas can be maintained in separate projects from the "main" application. It sounds a lot like what you are requesting so maybe you should look into that.
Hope it makes sense. ;)
I would look at making your system as loosely coupled as possible. As/when you add more applications, your website will become less and less reliable (since no component will be up 100% of the time, combining these will reduce your overall reliability). So you should build your system to cater for the non-major services being down (I believe the Amazon homepage, for example, has 100-ish services contributing to it, and as such it's built to be fault-tolerant)
Your APIs between services should remain as stable as possible, such that the implementations can change without breaking the coupling. You should also investigate automated testing of this at the web level (perhaps Selenium or similar?) since testing the individual services will give you little coverage re the overall behaviour.
You might find it useful to look at implementing a custom VirtualPathProvider. On my last project we had multiple ASP.NET sites which needed to share theme files (master pages, user controls, images, style sheets) so I created a VirtualPathProvider which allowed us to map a virtual folder (e.g. /Themes) to any physical folder on the hard drive (e.g. C:\Shared\SiteThemes).
It's not trivial but didn't take too long and hasn't caused any problems. Incidentally it turned out to be a great way to overcome the maximum component limit in WiX... Note that you can't precompile sites that use a VirtualPathProvider.
Use MVC Concepts from now. they give more extendability and flexibility for a robust applications.
You might look at using SharePoint. It's a pretty decent platform for ASP.NET application delivery, particularly if they coexist in an intranet environment; it gives you a lot of stuff for free.
Of course, it has very rough elbows, so to speak, so proceed with caution.
I wouldn't think of the applications as seperate but as modules of the overall portal.
I would recommend you look into MEF as this would seem to be a perfect fit.
http://blogs.msdn.com/hammett/archive/2009/04/23/mef-and-asp-net-mvc-sample.aspx