Let's say I have a Visual Studio solution with a Web project, a BLL project, and a DAL project. I'm trying to follow the repository pattern keeping my SQL code in the DAL with an interface that is referenced by the BLL.
I have a handful of common solutions for things such as error handling, usage logging, and other things that can be considered utility functions (i.e. not in the business spec). I'm keeping these in a Common project.
Here are a few ideas I've had with regards to structuring the Common project...
Bundle SQL with logic in a given class
Create a layered solution within the Common project
Discard the Common project and put utility functions in with BLL/DAL
Is one of these ideas better/worse than the other? Does anyone have a better solution?
It's worth noting that these utility functions will be reused in a variety of other applications.
Instead of creating a Utilities project which will be used have you thought about creating something that can provide a service? You might want to look at Aspect Oriented Programming. Red flags went up when I saw you listing off your examples error handling, logging, etc. Those scream AOP.
But if you want to stick with your layout.
I think I would go with 2, assuming that means restructuring the utilities project to be more Cohesive.
I don't understand (please clarify and I will edit my post)
Bundle SQL with logic in a given class
As for:
Discard the Common project and put utility functions in with BLL/DAL
I would be against doing so. If this logic is truly going to be repeated there is no need to push it back into your projects. This will lead to duplicate code and increased maintenance.
Side Note:
Just as a lessons learned, the only way Utilities projects work, are if you are the only developer or it is well documented and well designed. Sometimes utilities are too programmer specific, or are written in a way that only benefits a particular coders style.
I have seen countless times people rework their infrastructure pulling out all kinds of utilities, only to see their utilities project never get used. Make sure the "utilities" you are creating are truly useful to other people.
Related
I understand the need for abstraction and separating concerns and unit tests, however, it seems to me that separating entities and context into 2 projects is slight overengineering?
I could be missing something really, but is this because you want to be open for different ORM-s?
Much thanks for the clarification.
The main reason I prefer to have Infrastructure in a separate project, rather than just a separate folder, from the domain model (Core project) is simple: enforcing my design via the compiler.
I have a design rule, which is basically the Dependency Inversion Principle. Don't depend on low level implementations (such as those found in Infrastructure), instead depend on abstractions (interfaces). Also, don't have your abstractions depend on details; have details depend on abstractions. The details of how and which infrastructure is being used for a given abstraction are in the Infrastructure service implementations.
Abstractions say what; implementations say how.
What: I need to send an email.
ISendEmail interface
How: I want to do it using the SMTP protcol
SmtpEmailSender class (implements ISendEmail)
How: I want to do it using a SendGrid API
SendGridEmailSender class (implements ISendEmail)
So, in a single project, how would you ensure that the implementations depend on the interfaces, and not vice versa?
How would you ensure your domain classes didn't directly reference or use Infrastructure types?
I'm not aware of a way to do this.
But if you put them in separate projects, and you have the implementation details project depend on the abstractions-and-models project, you now have solved the problem. The compiler WILL NOT ALLOW the Core project to reference anything in the Infrastructure project, because it would create a circular dependency.
This constraint helps developers do the right thing and keeps them falling into the pit of success even if they don't completely grok how the dependency inversion principle works or why it's important.
And I've never found 3 projects (Core/Infra/UI) to be overengineering for any non-demo app I've built for real work. It's only 3 projects.
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
Do you have one solution with the web application project, class libraries, database project and tests? Or, do you segment it into multiple solutions? Why?
I'm asking because we're trying to streamline this scenario for Visual Studio 2010 and I'd like to get input from the community on how you'd prefer to work.
I tend (but not always) to have one solution per job, but I import existings projects from other solutions, such as my WebControlLibrary where I keep common user controls and classes, etc.
My actual solution for the job I then tend to break down into the Web Application, Business Logic Layer, Data Access Layer and Entity Layer, i.e.:
Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment
If a project requires something such as a mobile device, I'll always put that in a new solution, but it may perhaps share some projects of the current solution, i.e.
MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic
The more 'stuff' you have combined, the slower Visual Studios becomes at building. You can obviously stop certain projects building by default, but that's when you have to start creating your own build configurations. If you are going to be creating large applications, I'd suggest breaking down into multiple solutions. I find it much easier to flick between solutions that to keep changing build configurations.
Another option is that when you build your projects you can reference their DLLs. I prefer to import said projects into my solution as you never have to worry about referencing the creating build configuration i.e. selecting the DLL from the Debug or Release folder.
Stand alone libraries can be their own solutions. References for those libraries can be made into the project that you're working with. Related items like the web application, the test setups, and specific libraries such as data access or business rules can be setup as projects within one solution. It really all comes down to how much you want to break things out for resuability.
This depends a little on the job the project performs.
For ease of use it's simple to have a solution that just contains all the projects required. If it's a large solution this can hamper you later on when the IDE starts to get slow and build times rocket through the roof.
Let's say one of the projects is a library used by your company to take card payments and interface with 3d secure. You present you're own GUI page to take the details etc.
If you had numerous sites that all take card payments you would greatly benefit by having this project in a separate solution and referencing the compiled dll. Any changes you require you would need to open up the solution, make the change, build it, go to the solution you're working in and test it. Sounds like a pita and you find it's just simpler to have it all in one big solution. But then if you have this library in every solution and make a generic change to it you need to repeat that change through out.
So you just need to make a decision on wether you're developing a separate project in the same solution or something that might be used elsewhere. If you needed more functionality than the library provides you could implement a partial class in your project and extend the library in that way. Or perhaps a wrapper class will suffice. But then you know you're not affecting the other sites that use this library and you are keeping your solution smaller and more manageable with a smaller memory print during development.
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.