We are looking to build multiple custom websites for different customer contracts, with tailored functionality, but all around the same theme and concept.
There will be about 70% commonality in functionality across all websites, but enough difference that building a CMS is a bad choice. Also customers dont want their DB to have properties that are not relevant to them.
The DB tables will be mostly the same, with a few different properties in each table per site. ie a customer table might be 80% the same, but in one project in might also ask for hair-color, eye-color, etc. whereas in another in might also ask for height and weight....
I'm ok with my other layers, but what is the best practise for the MVC presentation layer?
I want to create as many inherited functions/controllers/actions/resx/etc as possible via base classes (which will be the same project referenced by each website), but MVC does not seem to lend itself as well to this as webforms.
Any thoughts would be really appreciated, thanks
I would focus my efforts on the web config and building my presentation layer around config settings stored at server side. Also, I'm not entirely sure how logically different your pages will be, but having different CSS styles can dramatically change the look of your websites. This post was kinda vague, I hope I helped spurn some ideas...
Related
I am thinking about Implementing an admin subdomain - for testing purpouses on the localhost.
I've been thinking, and it Would be preferable if the subdomain had its own set of controllers in different folder (f.e. Controllers/SUBDOMAIN_NAME/newHomeController.cs) or that it would be different part of the web working with the same models and database.
Everything I have read so far included quite big code of, for me as a newbie, magical routing, often leaving the link creating, so much needed in views, unanswered.
Other way I have heard of is to develope it as another project, but that doesnt seem to be the way to go, especially if I want it to be at least a part of the project (same models and db).
I can imagine I am not the first doing that and that this might be VERY common intension so I hope there might be a SIMPLE way to do it (including creating links in view)
I would appreciate any insight into a complete solution of this "problem".
Background
There are a lot of good resources on how to use MVVM/MVP to separate your layers so that the designer and coder can work separately. This isn't a PRISM question, but I have also checked several Prism tutorials ( including this excellent 4+ hours series by Microsoft' Mike Taulty, and many more)
These tutorials/books/videos explain the internal workings, such as how to pass messages across view models, how to modularize the application, the best security practices and so on.
However, no one talks about how to actually *logically divide*an application (WPF or ASP.Net MVC) so that multiple people can work on it.
Question
How do you generally go about assigning responsibilities to your development team?
Assuming that you use a high level UML tool, once a high level diagram is ready but no code has been written, how do you ensure that
1- The developer(s) working on the UI will know and be able to access the class library functions that the class-library developers will write?
2- Two libraries that will be written for two different purposes by two different developers will inter operate?
I hope I am not being confusing here. The question is just for a few good rules of thumb. That as two people working on two projects ( WPF/Silverlight or ASP.Net MVC) in a solution will take two different ways , how do the methods/classes/functions written by one fit together with the others?
Thank you
However, no one talks about how to actually *logically divide*an application (WPF or ASP.Net MVC) so that multiple people can work on it.
You don't really need to divide an application so that multiple people can work on it: you can also use a Team Foundation Server. There's also a free version available for 5 users or fewer.
Tutorial: Getting Started with TFS in VS2010
As I understand of your question(s), you want to have an infrastructure in your project that people with different skills can work separately. If I were right, "Domain Driven Design" would be the best infrastructure you can choose.
Domain-driven design (DDD) is an approach to develop software for complex needs by connecting the implementation to an evolving model. The premise of domain-driven design is the following:
Placing the project's primary focus on the core domain and domain logic.
Basing complex designs on a model of the domain.
Initiating a creative collaboration between technical and domain experts to iteratively refine a conceptual model that addresses particular domain problems.
The term was coined by Eric Evans in his book of the same title.
There is a great project that can help you: Microsoft Spain - Domain Oriented N-Layered .NET 4.0 Sample App is based on simple scenarios easy to understand which is well documented.
Concepts like modularity, layering, etc. are discussed in the project very carefully which I believe can fulfill your expectation.
Obviously, you need a source control like Team Foundation Server or other alternatives that provide control over changes to source code among multiple developers.
That as two people working on two projects ( WPF/Silverlight or
ASP.Net MVC) in a solution will take two different ways , how do the
methods/classes/functions written by one fit together with the others?
You need maintain some common library for public functions. And the two developers need to make code review every 2 or 3 weeks. So they could find their difference and learn from each others.
I recently attended a demo of a large-scale enterprise system, whose web pages may be customised to the point of including fields added by the client. The way I understand it, their architecture is made up of the following layers:
Database
Web service API
XML files that dictate layout
The web pages that are generated from the XML files.
When I was asked to investigate building a web portal which could be easily branded, that struck me as a good way of going about it. The question now, is how one would design it.
I understand the database and web service layers, but I am a little confused by the various possibilities for building web sites in .NET.
Considering the requirement for customisability and the architecture from above, here is how I understand the options:
Webforms - the option I am most familiar with, but it is essentially enriched HTML with code-behind. I think there will probably be a lot of work to make it work with the idea of an XML layout.
WPF - the XAML middle layer is built-in, but as I understand it, WPF can only really be used in browser applications and not websites.
Silverlight - more for building applets than websites, right?
MVC - This looks interesting, but all the demos I have seen use Entity Framework as well. It seems to me like Entity Framework with all its automatic code generation is much more suitable to applications that are all new. In my case, I have a very large database that already exists.
If none of the above are suitable, I thought of an alternative. One could do a stock standard Webforms site with a web service that returns the branding elements. That isn't quite the same as what I described at the top, but is sufficient for my needs.
Or am I barking up the wrong tree?
I think you're off on your criticism of MVC. First, you don't need to use Entity Framework, and secondly even if you did, you can do it database first to generate your entities.
Your assessments of WPF and Silverlight is pretty spot on imo.
You could do this with webforms, but I think you'll probably find doing it with MVC architecture will be cleaner. Very simply, if you use clean HTML and put all branding elements into an external CSS file (logos, colors etc), then you are half way there to a custom brand. Even a different layout could potentially be defined by the CSS file (although it might be harder for your end users to customize that look since they would need to know css pretty well)
Building additional fields is potentially more difficult:
Off the cuff, the way I'd be looking at implementing this would be a combination of my predefined fields in a standard database layout (users table with username, password, first name, etc etc) and additional support for the "customizable fields" using the Entity-attribute-value pattern
From there you will need to develop an extensible system to 1. generate a page from xml with the appropriate form elements (select, text input, textarea, etc). 2. Generate a generic model that will read the same XML file and be able to receive data from a posted form and know how to save that to the database (note in this case if it was ALL entity-attribute-value that would probably be easier to manage than a combination of standard relational and EAV).
You'll probably want to look at .NET Data Contracts as serializable entities to get an understanding of how you might design your XML files to be extensible to allow for things like "select menu has the following 3 options" or text input must match this regex.
Really keep an eye towards extensibility, because you can't build it all at once.
As I'm typing this, I'm realizing that it's very hard to explain. My apologies if it's indiscernible. My end goal is to have someone with more experience look at how I'm structuring my solution and provide feedback on whether or not it is an acceptable setup.
I currently manage several small support projects that are loosely related to one another. They are all over the board. I want to create a unified INTERNAL-WEB application to manage these projects. I've managed to group everything conceptually into three domains. SHIPPING, EXTERNAL-WEB, INTERNAL-WEB. From a business perspective, SHIPPING sends WIDGETs to CUSTOMERs which then connect to EXTERNAL-WEB. The problem is that SHIPPING's definition of WIDGET and CUSTOMER is different than the EXTERNAL-WEB definition, so I need to break these two apart.
After some thinking, I've come to the conclusion that the best way to organize this in VS2010 is to create a solution and then nest multiple projects within the solution. I'm envisioning a layout like the following.
SOLUTION
---SOLUTION.SHIPPING.Domain (Classes)
---SOLUTION.SHIPPING.Infrastructure (Classes)
---SOLUTION.EXTERNAL-WEB.Domain (Classes)
---SOLUTION.EXTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.INTERNAL-WEB.Domain (Classes)
---SOLUTION.INTERNAL-WEB.Infrastructure (Classes)
---SOLUTION.WebUI (MVC3 Project)
I'll have to add additional projects for context maps and anti-corruption layers to allow communication between domains, but this is the basic layout.
Is this smart or is it stupid?
Thanks,
Greg
How you have configured your solution has nothing to do with DDD and won't effect the success of your project. Good code that is organized badly is much better than bad code that is organized well.
Projects have a productivity and complexity cost associated with them. Right now you are agonizing over details which don't really matter.
More projects also equals slower compile times which increases context shifting. Try reading a book and pausing for 30 seconds every page.
New projects should be created for either deployment or code sharing purposes. Good reasons include if the domain is shared between two front or if you have a monstrous deployment strategy ( 1000s of machines ) and megabytes still matter.
Once you simplify the rules for new projects the decisions start to be made naturally as the codebase matures and new requirements pops up. You are essentially making physical decisions at the last possible moment. This is good. Don't BUFD this when you have features and code to write!
Not sure why this question is tagged MVC but the MVC codebase is pretty lean with only 1 main project. Compiles fast and is really easy to navigate around.
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.