I've been seeing a lot of articles and references about how to use this patterns for my first (please keep this in mind) serious project with ASP.NET MVC 3 and EF.
The project is not so big (13 tables) and it's basically a CRUD maintenance: organisations that have some users; users that can belong to a group and can create some work areas and templates... Nothing complicated. The point is that this will be the first of a project series and I'd like to create a base to work with.
My questions are:
Which of the previous patterns is the best? Does it depend of the project size?
My models would be these:
Unit of work
Dependency Injection
Do you think they are good enough and appropriate for my project?
I appreciate all your comments.
Serious application doesn't mean to be complex at first sight.
Over engineering an application upfront can be a real disaster, especially if you don't grasp all the technologies involved.
My advice would be to keep it simple. Create a basic application that fulfill requirements (get the thing done and make your boss happy) and then add new concepts along your learning path.
That doesn't mean I promote bad code, no way! Keep your code clean, well organized, etc. But don't be killed by the fear of doing something wrong.
It's normal for a developer to look back to an application made a few weeks ago and then realize that he did some shitty stuff. That's how we progress!
Last but not least, have FUN!
ASP.NET website provides usefull resources to learn the framework and all related guidances. There are a few application samples created step-by-step.
ASP.NET MVC was built with Dependency Injection in mind.
If you want to give a chance to your code to be loosely coupled and easier to change in the future you have to follow the patterns like Dependency Injection, Repository (for presistance abstraction), and UoW (for transaction abstraction).
So my answer is, you should learn about them in the first place to decide after if you want or no to follow the best practices. Even for simple project it's good to apply these patterns because often it gets bigger and bigger. and it's easy to do it in MVC so why to avoid it ?
There is many resources around to learn about. You can just google it.
I would like to answer this question in more generic way. Creating something which can be used in future is difficult than what it seems. All the pattern above can provide you infrastructure pieces to come up with some base framework.
But I would strongly suggest you to look at S.O.L.I.D principals (DI being part of it) to understand some qualities of good code. These are applicable irrespective of the technology involved.
You cannot predict the future requirement of a product\framework, but following these principle you can be better prepare to handle any future modification to the software
You might want to check out S#arp Lite which has many good examples of how to implement the things you want and can serve as a very good base on which to build something quickly.
None of the mentioned patterns are mutually exclusive. You should use the patterns that make sense based on what you are trying to accomplish, not attempt to shoehorn your application design into someone elses idea of how it should work. Sometimes trying to bend your scenario to fit a particular design pattern / practice is the worst thing you can do.
Want to make sure good unit test coverage / do TDD / ensure loose coupling? Then Dependency injection is your friend, as is the Unit of Work pattern. This is definitely a good idea for creating a maintainable, scalable application, but you can go too far with it for a small-scale application.
Need a centralized caching strategy for your data source? Then use the repository pattern. Or an ORM like NHibernate, which might do it for you.
Related
I have spent a lot of time searching for best practices for designing a ASP.NET MVC 3 web site using EF 4.1 or another ORM. I found this tutorial on Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application . It was a good tutorial and I learned something. So this got me thinking and wanted to know from the people on stack is this something you would use? if not why and how did you design your web site? I just want to learn the correct way to do things and understand why one way is better then the other.
First to say Entity Framework implements a Repository pattern and a Unit of Work Pattern. Implementing Repository and Unit of Work patterns on top of a modern ORM like Entity framework is an additional layer of abstraction that:
narrows the possibilities of the underlying ORM
does not provide additional value to the underlying ORM
is at best worthless but may be harmful
One purpose of such implementations is to encapsulate the query logic in the Repository and not one query like Single Responsibility Principle (SRP) would suggest, but a couple of queries and thus violating SRP. What you could do is to rely on your ORM and encapsulate extensive query logic in single Query classes.
My suggestion is not to please "best practices" by adding abstraction layers on abstraction layers and so on but to try to solve a problem using some more general design guidelines such as SOLID.
Ayende Rahien reviews the Northwind Starter Kit application in a series of blog posts (here, here, here, here, here, here, here and here) in his blog that deal with so called best practices applied in an application. This is a great read!
I have just started looking into .net MVC and I really like it.
There are a few developers within our team who think the same. But before we are allowed to use it for any project we need to get the approval of management.
What would be the best way to convince management(which know little about programming) that this would worth while and it could have some cost benefit?
My belief is that it will force us to write better more accessible sites which are a lot more testable than web forms. Which in return would mean less bugs and higher customer satisfaction. But I have no evidence of this.
EDIT:
We have a team meeting in 4 days, this is where I will be making my pitch to the team and management.That gives me two weeks to learn more on MVC and do a presentation.
Ok, I'm a manager. I've been one for more than 10 years. Luckily, I've been able to stay very current with my technology passions, so I think I can speak from both sides of the fence.
Managers are going to be concerned with three things here: risk, cost, and the status quo. So, when you present your plan, you're going to need to address each of these:
Risk:
Explain to them that the risk here is very low.
MVC2 is just an extension of MVC, both of which has full source code available (management speak: if we find a problem, we don't need support. We can fix it ourselves).
There's a ton of community support. (management speak: I can go online and get answers to any questions I have in a matter of minutes).
Heavy-hitters at Microsoft are pushing this (management speak: Microsoft is encouraging their developers to use this technology).
Cost
Talk about the fact that the technology is free, with a ton of community support.
Be ready to talk about ramp-up costs for any developers that don't have MVC experience. They're going to be less productive at first. Let your manager know that the developers will come up to speed quickly, and that MVC provides more efficient coding approach than traditional web forms.
Be ready to talk about costs and risks associated with ongoing maintenance. If you've already got a ton of web forms out in the wild, this will present a second skillset that developers will need to maintain. Find ways to convince management that it will be possible to maintain this skillset.
Status Quo
Many people become managers because they want a level of security and control in their life. If this is the case with your manager, they'll be interested in maintaining a comfortable status quo, and not making significant changes. If that's true here, you need to make the case that this really isn't a major change from what's being done today. Assure them that you have a back-out strategy. Talk about how this is really a proof-of-concept for MVC use in your organization, and that management will have an opportunity to review the success of the project prior to you ever suggesting MVC become a standard.
Really what it comes down to is the fact that ASP.NET MVC forces developers to write better, more scalable, and easier to test code. It moves them away from the crapshoot that webforms often can be, and in a direction oriented toward quality architecture and good clean code that follows more rigid conventions.
One definite drawback of MVC is that the View structure required by the webforms view engine (default) encourages you to write spaghetti code in the views that is, at times, a nightmare to maintain. Given this fact, you might even want to pitch them with the new Razor View Engine that was recently announced. With it you can write some extremely clean view code that even the non-developers at your company could manipulate without bringing mass death and destruction to your application. Compared to the markup in the webforms view engine, Razor's markup is pretty much beautiful.
Also, check out this really solid blog post by my buddy Matt Hidinger which does a great job of breaking down why MVC is so awesome.
When you speak to management just be sure to emphasize the all good points mentioned so far, and then compare them to all the bad that webforms is/can be. Be practical and realistic; if you have enough people on your team that are ready to jump on board with MVC then it's pretty much the best possible decision you can make, in my opinion, anyway. You may even want to take a moment to show them some of the great sites that use it- like Stack Overflow.
Personally, I have launched about 15 separate sites built with ASP.NET MVC and as such I feel I have a pretty solid understanding of it. I can wholeheartedly tell you, from my experience, MVC is the best thing that ever happened to ASP.NET.
It really depends on what you're comparing it to, but assuming it's an alternative to webforms, a few items to mention:
better testability
more control over output, which can help target other devices
leverage existing knowledge of .net
MVC framework encourages you to write more structured, testable and, as a result, more maintainable code. As the biggest costs in development are in the debugging and maintenance, those benefits alone should be a good validation. That said, it's still possible to code crap in MVC and that shouldn't be overlooked. If your company has a lot of expertise in another development framework then you really need to address the deficiencies in that and how MVC can rectify those deficiencies.
I would start by looking up blog sites that support MVC and compiling some of the advantageous features of MVC. I would start with Scott Guthrie's initial blog post regarding MVC - it outlines some great features - http://weblogs.asp.net/scottgu/archive/2007/10/14/asp-net-mvc-framework.aspx
If you are looking at trying to bring MVC in and need to convince management of the value, your best approach is too show how it can reduce long term support costs. Having an application that has well developed unit tests with decent code coverage can ensure quality over the life cycle of the application because you can higher level of confidence that changes you introduce have not broken pieces of the application. This doesn't negate the need to test the application, but you will find breaking changes faster. An approach utilizing MVC over MVC is a much more flexible platform for this testing.
There are many studies you can utilize that show the long terms support/maintenance costs of an application are often greater than the initial development costs. Stephen McConnell's Code First has a good discussion of this.
Good luck!
As opposed to what? Management would rather you wrote poorly-designed code? I'm surprised it's even an issue, in that whatever else they're asking you to do, by the current state of the industry, is self-evidently the wrong decision. If they know what MVC is, I can't see how any reasonable person would want you not to use it.
Sell it as an ASP.NET component, only made by Microsoft to incorporate some of the newer web 2.0 technologies moving forward. Tell them it will enhance maintainability while reducing development time. Tell them it uses existing infrastructure, and is more performant. Tell them it uses existing investments in training and software. Tell them it is more efficient, and makes it easier to fix issues and build enhancements. Tell them they'll get more out of their development team without allocating more resources.
I want to learn a framework that promotes good programming practices and is respected by the programming community.
However, I also want a framework that I can use for a day job.
Which one would you recommend?
This question comes from my experience of learning the basics of Django because it was highly acclaimed by developers on Stack Overflow and Hacker News. However.. there's hardly any jobs in my area (NYC) that are asking for Django developers.
As a long-time ASP.NET guy, I've recently gone through a similar decision process to figure out what other web frameworks I should try. Here's what I learned so far which may apply to your case too:
framework/platofrm choices (and hence job opportunities) are highly regional-- the Bay Area job market differs alot from what you'll find in NYC, Chicago, Montreal, or London. Look at local job listings (craigslist and indeed are good places to start) to get a good sense at what's in demand.
similarly, usage varies alot based on the size and type of company. if you want to get a job in a large company, Spring MVC and ASP.NET MVC may be your best bets. In small companies, DJango and (especially) Rails seem to be on the rise.
usage also sometimes varies by industry. for example, many HR apps seem be to .NET based, while financial/banking apps seem to favor Java. if you want to work in a particular industry, check out what up-and-coming companies in that industry are using.
when investing your scarce time in learning something new, favor technologies which are on the upswing of the adoption curve (e.g. Rails) rather than frameworks with wider adoption which may not be growing as fast. Also be wary of very early or niche frameworks which may not ever gain wide adoption.
the one common thread between most (or almost all) frameworks gaining in popularity is that they're MVC frameworks and rely heavily on a solid understanding of REST. Learning those concepts in depth is a good idea.
before deciding to invest a lot of time in one framework, gain a basic understanding of several of them, so you can get a reasonable sense of what you like and don't about each-- and so if you end up applying for a job using a framework you haven't learned, at least you'll be able to talk intelligently about it.
If you focus on what you enjoy, you'll be more motivated to learn it. For example, personally I found Rails (regarless of employment opportunities) more interesting than Spring or Django, so I decided to focus on Rails first. Others may have different impressions-- follow your programmer instincts. That said, there are often few jobs using technologies you find fascinating, so try to strike the right balance: technology you like that many companies are actually hiring people to use!
once you answer the basic "what framework" question, there are many more questions lurking, including picking a javascript framework, validation framework, an ORM, etc. Don't worry too much about those choices yet-- when starting, just pick the default implementation for your framework. But as you get more advanced, the same argument about frameworks also hold for those other things-- e.g. it's useful to know a few ORMs.
Personally, I decided on this approach:
continue building stuff in what I knew best (ASP.NET) but transition all work to ASP.NET MVC, where I can better understand MVC and REST concepts which apply cross-platform
learn JQuery (again, platform neutral)
blow off the ORM choice alltogether for now-- too many other things to worry about
build a few projects in Rails, which is the framework I see used most in the newer SF-Bay-Area startups I've been looking at
learn the basics (e.g. read a book or two, try a few samples) about Python/Django, Java/Spring, and Groovy/Grails.
I've encountered real projects at cool, small companies using Django, Ruby on Rails and (eiuw!) even Zope. .NET is for teletubbies - I've only ever heard of it being used by big corporations that don't know better.
I would say that knowing two or three is better than knowing one that is widely used because you will gain a better understanding of how it works as a concept. For instance if you've only used Java, there is something probably missing in your understanding of OOP, because you're pigeon-holed into thinking about it in one way. If you already know Django though you Spring would probably be a good compliment to that.
i'd probably say ASP.NET MVC. I always see lots of .NET jobs around and this seems to be a solid framework which i think in fact powers all the stackoverflow family. As a PHP developer i must also make a mention of Zend Framework which is used by a number of big sites including bbc.co.uk and is now frequently mentioned in advertisements for PHP jobs.
I want to learn a framework that promotes good programming practices and is respected by the programming community. However, I also want a framework that I can use for a day job.
Sorry to be the bearer of bad news here, but those two desires tend to conflict. IMHO most business managers tend to go for (ugly) rapid development on top of CRMs or other higher-level 3rd party codebases. Building elegant websites from the ground up mostly happens in startups, or true web companies where the website is the sole product. There are not that many of those companies; and many of those that seem to fit are actually a mess on the inside, i.e. due to time pressure, messy legacy code and many other reasons you often don't get to write according to "good programming practices" anyway.
I agree with Kaleb Brasee that Java and .NET are the two main platforms when job availability is a priority.
Every job market is unique, so look at job openings in your area, or call a handful of recruiters and ask what they see a need for / could easily place you in a junior position for. What I'm seeing is that Microsoft Sharepoint is in demand, and a few other regional CMS'es are in demand (in Denmark I see Sitecore regularly).
I think ASP.NET MVC 2.0 together with MVC Areas and ASP.NET Dynamic Data will have a good story, a good solution, for many of those bosses who want rapid development. And I think the resulting code could be quite okay, or at least not bad compared to many of the "CMS beaten into something else" sites that exist. But this is a brand new thing for the .NET platform, and it will need to be sold to the decision makers first...
Bottom line: If you want job security first and foremost, then look at large CMS's like Sharepoint, and work on other technologies in your spare time. Optionally you could take a job at a startup / a web company later; but look before you leap.
Have you tried Spring MVC? Many companies do use Java for web-apps (or .NET) and web service based applications.
Since you mentioned Ruby on Rails, you might want to learn Ruby on Rails. It has got some good programming practices in it and a very well thought architecture. The Ruby community itself have also (in my personal opinion) created very innovative frameworks and highly favor testing and quality. You can see this by the innovative testing framework like Cucumber, webrat, shoulda, coulda, rspec, test/spec. Many startups also uses Rails as their platform, so it should be easier for you to get a job. You can start looking at Working With Rails and 37signals job board. So there is a good ecosystem inside Rails and Ruby community.
But the downside of Rails compare to Django is mainly there are too much magic (less explicit) and the docs is not as good as Django. If you want to get a Django job, try looking at several news site because Django grew up from a newspaper site so it is adopted alot in news based sites.
I would recommend ASP.NET MVC, Ruby on Rails, or Python/Django, they all seem to be popular and successful, and based on the MVC paradigm which is definitely the right tool for the job when it comes to the web.
.NET and Java are by far the 2 largest platforms used by employers, and hence the most in-demand when searching for a job. Java has a few popular frameworks, with JSF, Spring MVC and Struts all seeming to be about equal in demand. I don't use .NET, but from what I've seen, ASP.NET and ASP.NET MVC are the major ones.
I would say that most of the frameworks mentioned here promotes good practices. But that doesn't neccesarily mean that the companies using those frameworks are actually following those good practices! In fact most probably aren't. So don't expect too much.
You see, places like Stack Overflow, Hacker News etc. are a great way to connect with people who really care about their craft. Sadly this is a minority. There are millions of programmers in the world. Most of them suck. The code they write sucks. They don't care. They are not interested in improving their skills. They just want to learn the bare minimum required to collect their paycheck, go home, feed the dog, spend some time with the family, watch some TV, go too bed and do it all over again the next day.
Okay that was a bit harsh :) What I'm getting at is that you are probably better off asking this question to some of the managers at the companies where you would like to work. My guess is that most of them will answer .NET or Java. If you are up for a laugh ask them why they chose that particular technology over something else, and see how many buzzwords they throw at you ;)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
update: I know there is no one best way to do everything. Sorry for not saying that right off. In the context of the data-access tutorials, if you had to do the project he did in that tutorial, would you do what he did or would use use MVC, if you had to choose one of them?
Update: Is MVC the more appropriate way to program asp.net applications, instead of the tutorials found here:
http://www.asp.net/Learn/data-access/
Original:
I ask, because I initially learned about MVC with Java applications, then things like RoR, and Django. These other projects and companies spoke as if MVC had been around for a very long time, and from what I found out it had. Then Microsoft started putting MVC into the .net framework.
I ask because I don't know how to design things very well and thought I was doing well to emulate what's on the asp.net site with Scott Mitchell's tutorial. I thought that creating abstract layers in a BLL was the way to go until I found out about MVC and now asp.net's MVC.
I honestly don't know what the "right" way is to do things. I just create what I need, but I can't help feel like I am missing something.
Is MVC the correct way to start doing things in large projects, specifically I mean MVC and ASP.NET, but could just as well mean PHP and one of their MVC frameworks.
I'd like to settle on a standard way of doing things...for now anyway.
And, out of curiosity, why did Microsoft only now start doing MVC?
UPDATE: Is MVC better than the current tutorial set on asp.net?
I'm referring to the Scott Mitchell tutorials where he creates the BLL for abstraction. Or is that a linq question as well. I should have said that I understand the need for keeping logic and presentation separate but unsure the best way to do it. I was using the asp.net tutorials. It worked fine. Then I found out the rest of the world, as I saw it anyway, was using MVC. Then Microsoft started developing MVC, so to me the other method seems obsolete and the wrong way to do things.
No, it's not the only best way to do things.
MVC is just a design pattern. The goal of all design patterns is simplicity. So as long as it makes your design simpler, go with it. If it makes things more complex for your specific application, try a different approach.
Unfortunately, some people think if they see a pattern, they should use it. It's just not true. Design patterns don't inherently make your application better. They are not an end. They are a means to an end (which is simplicity). So you should use them only if they are worth it.
In my opinion, over-architecting things without a good reason is worse than writing code without any specific design.
EDIT: Regarding ASP.NET MVC: I have a negative personal bias toward ASP.NET Web forms. Before MVC, I did most of the dynamic aspects of advanced projects by writing custom handlers to have fine grained control over the HTML. Web Forms make Web development very easy but they have particularly a couple things that are good but sometimes are problematic. The first of which is ViewState and the second is complex WebControl architecture. Don't get me wrong. Those are signs of brilliance of ASP.NET. I haven't seen a single platform for Web development as easy as ASP.NET Web Forms and this is only because of great WebControl support which requires ViewState. However, in some projects, you want to have precise control on rendered HTML (specially when you have some client-side logic). You also want to make server side code maintainable in large projects. In those areas, ASP.NET MVC really shines. But I think ASP.NET Web Forms will remain a great technology where it's more applicable. After all, as I said regarding design patterns in general, you should carefully evaluate your design to see which one better fits your needs.
Specifically, about data access, MVC usually requires more code than Web Forms counterparts. For presenting tabular data (i.e where GridView is applicable), I think ASP.NET Web Forms is the easier way to accomplish things. However, most data driven Web apps are not just manipulating a table directly in a database. They have complex layout. StackOverflow is a great example of this. It is certainly data driven, but ASP.NET MVC better suits it.
There is no "right" way to do things without knowing what "things" are. MVC is a design pattern that solves a specific common problem - separation of presentational and domain logic. Every design pattern is a commonly accepted "good" solution to a specific problem.
Those solutions, combined with knowledge and experience are building blocks for a good design. The "right" way to do things is to study your problem domain, research on possible solutions and apply the set of solutions that work best to solve it. Making mistakes is a part of the process as well, so don't be afraid to experiment and then refactor with rigor until you reach the solution that serves you best.
MVC is the worst way to develop applications, except for all other ways that have been tried. :-)
Joking aside, MVC is one application design that encourages us not to write spaghetti code. It's a guideline that reminds us to keep business code separate from presentation code. This is very helpful as the application gets more complex.
There are other variations that achieve that same benefit, but are not strictly the same as MVC. Presentation-abstraction-control (PAC) is one example.
As for why Microsoft is so late in adopting MVC, I'm not surprised that they are. They are pretty well-known (at least in recent years) for being conservative instead of innovative. They prefer to let other smaller companies take the risks in an unproven market, then they learn from the mistakes, churn out an overengineered competitor solution, and dominate through marketing.
Example: Microsoft Internet Explorer was considered to be a latecomer to the browser market. Netscape had become very popular, leading the way in providing a platform for people to view HTML. Once the amount of HTML content on the Internet was at a useful level, Microsoft belched up their onomatopoeic "IE" product and quickly captured an overwhelming market share.
MVC is just one way of doing things. I like it because it helps to promote extensibility and is structured to allow testing and code reuse. There is no silver bullet, one true way to do everything but I use it quite often.
In regard to Microsoft, I would say that they adopted the pattern as an alternative to WebForms development for the reasons I mentioned above. I would recommend looking at Rob Conery's MVC Storefront and kind of play around with the examples to see how it works for you.
There is no "best" way to code things. It depends on the application in question; sometimes MVC is the right choice, and sometimes it's not. A good developer is able to weigh his/her options and choose the one that's best suited for a task at hand, instead of just going with the method du jour
If MVC solves the Primary Technical Imperative of managing complexity in your application then it may be a good solution, but it is by no means the only solution.
MVC is one of any number of design patterns. Whether it's the best technologically, or the simplest, or for what types of projects it's appropriate, are are all arguable (see other SO threads). In any case, few would argue against the prevailing consensus that for most cases, it's "Good Enough".
But it has the undeniable benefit that a lot of people use it, on a lot of different platforms.
So if you want to use a methodology that is likely to be around a while; or you don't want to depend on one vendor for support and extension and refinement; or you work in a group that would like to grow by hiring people from various backgrounds who will grok a shared methodology quickly; or you would like to maximize your opportunities to move on if you need to, then MVC is one of the very best ways to support those goals.
MVC being "Better" or "Worse" pattern is relative to the project.
I've got to do some significant development in a large, old, spaghetti-ridden ASP system. I've been away from ASP for a long time, focusing my energies on Rails development.
One basic step I've taken is to refactor pages into subs and functions with meaningful names, so that at least it's easy to understand # the top of the file what's generally going on.
Is there a worthwhile MVC framework for ASP? Or a best practice at how to at least get business logic out of the views? (I remember doing a lot of includes back in the day -- is that still the way to do it?)
I'd love to get some unit testing going for business logic too, but maybe I'm asking too much?
Update:
There are over 200 ASP scripts in the project, some thousands of lines long ;) UGH!
We may opt for the "big rewrite" but until then, when I'm in changing a page, I want to spend a little extra time cleaning up the spaghetti.
Assumptions
The documentation for the Classic ASP system is rather light.
Management is not looking for a rewrite.
Since you have been doing ruby on rails, your (VB/C#) ASP.NET is passable at best.
My experience
I too inherited a classic ASP system that was slapped together willy-nilly by ex excel-vba types. There was a lot of this stuff <font size=3>crap</font> (and sometimes missing closing tags; Argggh!). Over the course of 2.5 years I added a security system, a common library, CSS+XHTML and was able to coerce the thing to validate xhtml1.1 (sans proper mime type, unfortunately) and built a fairly robust and ajaxy reporting system that's being used daily by 80 users.
I used jEdit, with cTags (as mentioned by jamting above), and a bunch of other plugins.
My Advice
Try to create a master include file from which to import all the stuff that's commonly used. Stuff like login/logout, database access, web services, javascript libs, etc.
Do use classes. They are ultra-primitive (no inheritance) but as jamting said, they can be convenient.
Indent the scripts properly.
Comment
Write an external architecture document. I personally use LyX, because it's brain-dead to produce a nicely formatted pdf, but you can use whatever you like. If you use a wiki, get the graphviz add-in installed and use it. It's super easy to make quick diagrams that can be easily modified.
Since I have no idea how substantial the enhancements need to be, I suggest having a good high-level to mid-level architecture document will be quite useful in planning the enhancements.
On the business logic unit tests, the only thing I found that works is setting up an xml-rpc listener in asp that imports the main library and exposes the functions (not subroutines though) in any of the main library's sub-includes, and then build, separately, a unit test system in a language with better support for the stuff that calls the ASP functions through xml-rpc. I use python, but I think Ruby should do the trick. (Does that make sense?). The cool thing is that the person writing the unit-test part of the software does not need to even look at the ASP code, as long as they have decent descriptions of the functions to call, so they can be someone beside you.
There is a project called aspunit at sourceforge but the last release was in 2004 and it's marked as inactive. Never used it but it's pure vbscript. A cursory look at the code tells me it looks like the authors knew what they were doing.
Finally, if you need help, I have some availability to do contract telecommuting work (maybe 8 hours/week max). Follow the link trail for contact info.
Good luck! HTH.
Since a complete rewrite of a working system can be very dangerous i can only give you a small tip: Set up exuberant tags, ctags, on your project. This way you can jump to the definition of a function and sub easy, which i think helps a lot.
On separating logic from "views". VBScript supports som kind of OO with classes. I tend to write classes which do the logic which I include on the asp-page which acts as a "view". Then i hook together the view with the class like Username: <%= MyAccount.UserName %>. The MyAccount class can also have methods like: MyAccount.Login() and so on.
Kind of primitive, but at least you can capsulate some code and hide it from the HTML.
My advice would be to carry on refactoring, classic ASP supports classes, so you should be able to move all everything but the display code into included ASP files which just contain classes.
See this article of details of moving from old fashioned asp towards ASP.NET
Refactoring ASP
Regarding a future direction, I wouldn't aim for ASP.NET web forms, instead I'd go for Microsoft's new MVC framework an add-on to of ASP.NET) It will be much simpler migrating to this from classic ASP.
I use ASPUnit for unit testing some of our classic ASP and find it to be helpful. It may be old, but so is ASP. It's simple, but it does work and you can customize or extend it if necessary.
I've also found Working Effectively with Legacy Code by Michael Feathers to be a helpful guide for finding ways to get some of that old code under test.
Include files can help as long as you keep it simple. At one point I tried creating an include for each class and that didn't work out too well. I like having a couple main includes with common business logic, and for complicated pages sometimes an include with logic for each of those pages. I suppose you could do MVC with a similar setup.
Is there any chance you could move from ASP to ASP.Net? Or are you looking at keeping it in classic ASP, but just cleaning it up. If at all possible, I would recommend moving as much as possible moving to .Net. It looks like you may be rewriting/reorganizing a lot of code anyway, so moving to .Net may not be a lot of extra effort.
Presumably someone else wrote most or all of the system that you're now maintaining. Look for the usual bad habits (repeated code, variables that are too widely scoped, nested if statements, etc.), and refactor as you would any other language. Keep an eye out for recurring things in the same file or different files and abstract them into functions.
If the code was written/maintained by various people, there might be some issues with inconsistent coding style. I find that bringing the code back into line makes it easier to see things that can be refactored.
"Thousands of lines long" makes me suspicious that there may also be situations where loosely-related things are being displayed on the same page. There again, you want to abstract them into separate subroutines.
Eventually you want to be writing objects to help encapsulate stuff like database connectivity, but it will be a while before you get there.
This is very old, but couldn't resist adding my two cents. If you must rewrite, and must continue to use classic ASP:
use JScript! much more powerful, you get inheritance, and there some good side benefits like using the same methods for server-side validation as you use for client-side
you can absolutely do MVC - I wrote an MVC framework, and it was not that many lines of code
you can also generate your model classes automatically with a bit of work. I have some code for this that worked quite well
make sure you are doing parameterized queries, and always returning disconnected recordsets
Software Development Project Management practices indicates that softwares like this are requiring to retire.
I know how hard it is to do the right thing, even more when the responsible manager knows sht and is scared of everything other than the wost way possible.
But still. It's necessary to start working on the development of a new software. It's simply impossible to maintain this one forever, and the loger they wait for retiring it the worse.
If you don't have proper specification/requirements documentation (I think no asp software in the world does, given the noobatry hability of those coders), you'll need both a group of users that know the software features and a manager to be responsible for validating the requirements. You'll need to review every feature and document its requirements.
During that process you'll go learning more about the software and its business. Once you have enough info, you can start developing a new one.