To make a projet manageable, we break it into sub-projets (class libraries in C#, for instance). Now, in ASP.NET MVC 2, we do have Areas. I'd like to know if Areas have or can serve the same purposes as class libraries? It looks like both are meant to make a project manageable...
Personaly, I'm about to write something bigger. I don't know which way to go: Area vs class library...both?
Thanks for helping
Making a project manageable is really not the point of areas nor class libraries, though they do have that effect when used well.
Generally, the purpose of a class library is more about creating a stand-alone library of code that all serves some inter-related purpose. The point is really that a well used class library represents a collection of code that is maintained, developed, and distributed as a single unit. The big key is the distribution though, since class libraries can be distributed and used in many applications. It is usually a waste of time to split code out into class libraries if those libraries are never distributed, maintained, or developed independently. If they exist just to organize and group code that is otherwise dependent on other code in other libraries then you may be making your code less manageable in the long run; namespaces and folders alone can serve the purpose of keeping code grouped, organized, and manageable.
Areas in MVC are a tad different. Their purpose is to partition large web applications into semi-independent segments that are all hosted in a single project (and thus are part of the same class library; an MVC app is just a fancy kind of class library). So the entire purpose of areas tends to be responsibility. The biggest advantage of areas is that they are useful to split large applications into sections that are maintained and developed by separate teams of developers; or into sections that have widely different infrastructure requirements from other sections of the application.
So in terms of manageability alone, areas are a good idea if your MVC app is large and has distinct functional sections. Class libraries can only be justified if there are other benefits aside from code manageability.
At the most basic level your comparing how C# is compiled into a specific framework feature.
Areas are simply built in routing/finding/searching customizations against so you can separate your app into different folders. You could provide your MVC application with a VirtualPathProvider and use views embedded in class libraries to segment your application but it isn't the standard way of organizing things.
Related
I am new to iOS development, so please excuse me in case my question sounds trivial.
I am planning to introduce MVP or VIPER pattern. I am from Web background and in web application we used to follow different layers/dlls (for model, view, common etc.). Does it make sense to follow the same layered approach (frameworks in this case) in iOS and or it will be overkill? I have not come across any sample project (based on MVP) which create different framework for model, View and Presenters? It would be great if someone can share any sample project (based on MVP) which we can use as a starter project.
Thanks In Advance
In iOS, we generally use MVC - Model/View/Controller. So, if you're looking for the analog in the iOS world, that's it. If you're saying that you've really dug into MVC and there's something that you find deeply unsatisfying, and therefore want to introduce a different pattern, then that's a different question.
So, no, the sort of logical separation of responsibilities that you see in approaches like MVC is not overkill. In fact, the division of "view" and "controller" classes are fairly central to everything we do (e.g. UIView subclasses, UIViewController subclasses, etc.), so the only thing you really have to do is design appropriate "model" classes and you're off to the races.
But, in answer to your question, you don't generally use separate framework targets for the model, the views, and the controllers. That probably would be overkill. Usually you can keep track of everything through through judicious use of Xcode groups/folders within your project. We generally only pull stuff into frameworks for more technical or logistical reasons (live views, app extensions, sharing code between multiple apps, etc. ... see WWDC 2015 Building Modern Frameworks for discussions of when you'd generally use frameworks).
But to the question of MVC vs MVP or VIPER (or MVVM or whatever). I'd suggest that you simply embrace the shared spirit of all of these patterns (namely the separation of responsibilities) and apply it to your iOS MVC code. Once you've got some iOS experience under your belt, you can then re-evaluate this pattern question.
If you're starting with iOS developement and is looking for a good architecture, go with VIPER. It's not at all an overkill as long as you:
1 - Automate VIPER files generation
2 - Automate VIPER modules initialization
To accomplish both requirements above, use this Xcode plugin (https://github.com/natangr/ViperTemplate) to generate and intialize VIPER files automatically. It works like charm!
And read this post https://www.ckl.io/blog/best-practices-viper-architecture to get more tips on how to automate things when using VIPER.
I do use it, even for very small projects (160h of development)
I read several questions on programmers.stackexchange.com to determine if this question is better asked there. I think this question belongs on SO, but I'm not completely sure.
I have a basic knowledge of Objective-C and UIKit. I have read, a few years ago, most of Cocoa Programming for OS X (2nd Edition) by Aaron Hillegass; this is where the majority of my knowledge stems. The rest is from various sites, SO questions, the SDK documentation, and small personal projects (both OS X and iOS).
I am starting an iOS (specifically, iPhone) project for the university at which I work. This application will have distinct sections with distinct functionality. Some examples of "sections" would be: a virtual student ID card, current semester's class schedule (for the user), a campus map, etcetera. I want to be able to add new sections easily in future versions of the application. Thus, I want to design the project such that a section is an independent, from the main project, group of code (as much as possible).
In addition to being able to add new features by creating new modules, I want the project to be usable by more developers that just myself. That is, I want other developers on my team to be able to develop new modules for the application by following a "best practice."
Currently, I am basing my project around a UITabBarController with my "modules" being new UIViewControllers and NIBs. I get the feeling that this might not be an optimal way of establishing my project. Thus my question:
What are some best practices for such a project as I have described?
I think you're on the right track. UIViewControllers are a good way to break this up.
UITabBarControllers are often awkward when you have a lot of options; a welcome screen with a table view of possibilities might be more expandable. See, for example, Facebook's left panel or the built-in Settings app.
I typically find that the hard part about reuse in iOS projects is not the view controllers (which are typically well isolated) but the underlying infrastructure such as that for network requests, data storage, account management, etc. You might want to start with an existing framework for this (like, say, Parse or RestKit), or at least look at how they break things up.
On the topic of good, reusable iOS design, you might find Matt Gemmell's post about API design helpful, if not exactly what you're looking for.
establish conventions for coding style and resource location.
develop static libraries.
if your static libraries require their own resources (which can be a necessary pain), you may want to use bundles for your resources to minimize resource collisions.
centralize your build configuration files, rather than attempting to define each setting in each project (use xcconfigs).
then you can configure these libraries as dependencies in your app projects, and build, link, and copy appropriately.
one important note: i often err towards C and C++ symbols in these cases (where applicable) because ObjC symbols (and what they reference)cannot be stripped. this can reduce a lot of 'binary fat' where not used. so your 'core' libraries and libraries which deal mostly with symbols declared in other libraries (e.g. system libraries) may be in C and C++, and your higher level abstractions and derived types may be in ObjC.
Currently there are multiple (about 15-30) independent web applications written in another language. Each one is completely independent with files, images, headers, users, databases etc. etc. The whole 9yards, except that they all exist under the same domain and should have the same style (but they don't). They will soon be converted to C# ASP.NET MVC 2. They do share the same LDAP authentication.
The question has come up in my mind as to whether these should be setup as multiple MVC solutions or be done within a single MVC application. They will all have the same styles, mostly the same images, and it would be nice for them to share basic functions.
The reason this isn't a simple cut and dry solution to me, is that some of these applications are quite large by themselves and throwing them all together might be hard to manage. Not to mention the development of new applications will continue as well as new features added to the existing ones. Making this possibly an extremely large solution.
I am fairly new to MVC and even though I have a good understanding of it now, I'm still trying to rewire my brain here and there to work with the methodology and design.
I guess what I'm asking for, is those of you who have more experience with MVC than I do to share some incite and wisdom about MVC in practical use to give me a direction to start thinking.
Please, make yourself a favor and do not combine them in a single solution. I worked once in a project where we had one huge solution to work and that was the root of all evil. If you place everything in a single solution, you are increasing the complexity of all projects, you might be thinking, I am actually going to save a few lines of code by reusing something, but the truth is that you are creating a deadly solution which will become a bottleneck eventually
Consider the following:
The performance of Visual Studio is affected when you have more than 30-40 projects, which means that your build is going to take more and more time.
If you implement a build server (and you should) if you have one huge solution, the script to build only the projects related to each application would be really complex
Now I think you already did the most difficult part of the design when you say:
Currently there are multiple (about 15-30) independent web applications written in another language
If your applications are independent that means they have an independent domain, so there is no reason to place them in a single solution, not even treat them as modules.
Managing independent solutions does not mean that you cannot have shared components among them, (BTW when I say shared components I mean infrastructure components, please do not try to reuse domain objects).
So now the question is how should I reference the shared components?
In these days, I have found that the best way to reuse infrastructure components among solutions-projects, is by using Nugets. Using Nugets makes it easy to distribute new version of the components, so my suggestion is: create a private Nuget server in your organization (a simple IIS application) and add to this server your own private packages and just reference them from your solutions
You can place in your Nuget packages practically anything you need including:
Assemblies
XML config files (including common XML logger configuration files)
Common JavaScript files
Common Style Sheets files
etc...
This is a good article to create a private Nuget repository
http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds
To create a Nuget:
http://docs.nuget.org/docs/creating-packages/creating-and-publishing-a-package
And finally to integrate the creation of a Nuget in your CI server:
http://www.hanselman.com/blog/NuGetForTheEnterpriseNuGetInAContinuousIntegrationAutomatedBuildSystem.aspx
http://docs.nuget.org/docs/reference/command-line-reference
When I go for combining multiple web applications into single.. I'll consider the below points.
If all the applications shares a common business model.
If they shares a common infrastructure (security, validation, logging and others..)
If they shares same a common user base.
If combining multiple projects into one helps me to reduce the cost of maintenance and enhancement.
In your case you said each one of them is completely independent then why you need to combine?
My recomendation is DI and create each proyect like a plug-in ,so each proyect can be developed or manage in separate without affect others
I have a few proyects with MEF and it's so easy create new or manage existents plug-ins
Here is a getting started MVC and MEF… http://blog.maartenballiauw.be/post/2009/04/21/ASPNET-MVC-and-the-Managed-Extensibility-Framework-%28MEF%29.aspx
and a downloadable example http://www.hanselman.com/blog/ExtendingNerdDinnerAddingMEFAndPluginsToASPNETMVC.aspx
The same style could be accomplished with a unified stylesheet referenced by all, as long as you use similar mark-up in your pages within the apps. Common functionality could be provided through a unified class library. To me, it really depends on exactly how close the style and functionality are between apps... do you want the exact same markup on every page, etc.
It is common to have an instance of the Controller per application, however if you implement this using a data driven Front Controller then there only needs to be a single Class within your new WeB Application framework. So each Application might have a configuration file that maps URL to Command Class files. These can be constructed on demand or requested from a Resource Pool. A big advantage of this approach is that many of these commands would start as a very thin wrappers (ServiceToWorker) over the existing application and/or ASP views.
I totally agree with Marks answer, ask yourself "why" do you need to combine them. Do they really need to be independent?
My additional comments though are....
What you should definitely think of....
Create a unified CSS files which use the same images to be used by your applications
Write some universal JQuery (Mobile version if these are public facing) using JQuery templates/partial views as well to give all these seperate applications a unified experience
If you are not going to unify your server side code in terms of the DAL etc, then just concentrate on the client side.
I'm doing research on software architecture, layering, and looked lots of open source .net projects, like Orchard CMS.
I think Orchard is a good example for some design patterns.
As I know, UI, Services, Repositories and Entities should be in separate assemblies, due to misusing. But in Orchard, (due to being modularity and pluggable) I see service, repository and entity classes and interfaces in same folder and same namespace.
Isn't it an anti-pattern, or is it correct for patterns?
TL;DR: assemblies are not necessarily the right separation device.
No, what's important is that they are separated, not that they are in separate assemblies. Furthermore, the way you would factor things in most applications has to be different from what you do in an extensible CMS. The right separation in an extensible CMS is into decoupled features that can be added and removed at will, whereas regular tiered applications require decoupling of layers so those can be worked on and refactored with minimal risk and impact. The right comparison is actually between one of those applications and a module or feature in Orchard, not with Orchard as a whole. But of course, good practices should be used within modules, and they usually are.
Now separation into assemblies is a separate concern, that is more technical than architectural. You can see an assembly as a container of self-contained code, created for the purpose of code reuse and dynamic linking, but not especially as a way to separate layers. This is why they coincide in Orchard with the unit of code reuse, the module.
Also consider the practical aspect of this: good architectural practices have one main goal, which is to make applications easier and cheaper to maintain (and not, surprisingly (NOT!) to make consultants rich by enabling them to set-up astronaut architectures that only they can understand). A secondary goal is to codify what makes scalable and well-performing applications (although that is a trickier goal as it can easily lead to premature optimization, the root of most software evil).
For that first goal, conceptual separation is the most important, but the way this separation is made is usually not very important.
The secondary goal unfortunately conflicts with the idea of using assemblies as a separation device: Orchard as it is already has dozens of assemblies before you even start to add optional modules. And assemblies do not come for free. They need to be dynamically compiled, loaded, jitted, come with memory overhead, etc. In other terms, for good performance, you'll usually want to reduce the number of assemblies.
If you wanted to separate an Orchard site into assemblies for modules as it is today, and then separate each of these modules into layered assemblies, you would have to multiply the number of modules by the number of layers. That would be hundreds of assemblies to load. Not good. As a matter of facts, we are even considering an option for dynamic compilation to build all modules into a single assembly.
I'm starting a new web application that will be made of multiple parts or modules.
My client want to be able to redistribute the application with a subset of modules to some other clients. I read about Areas in mvc2 which seems to be what i'm looking at.
I would also like to develop those modules in side projects and have the right one build according to clients specifications.
Can someone with more experience than me with mvc can confirm that this is possible with areas.
thanks
mateo
You actually don't need areas for this. If you develop each module in a separate project within a solution they will each have their own assembly. This should work unless I'm misunderstanding your requirements.
To further clarify: areas are generally used to separate a very large application into sections that may each have a different development team. For example stack overflow might have the question + answer engine area, the roles and permissions area, login and authentication, and so on.
I think each module should be a separate project (a single assembly/DLL with its own responsibilities). You'd "connect" each module as a lego :D. Then to redistribute the app with a subset of modules you'd have a build script where you specify the modules that are in and out of the final product. Each version of the product would come in different shapes (as in the lego game) presenting different functionality subsets.
Just to mention, the concept of Areas in MVC is this:
To accommodate large projects, ASP.NET
MVC lets you partition Web
applications into smaller units that
are referred to as areas. Areas
provide a way to separate a large MVC
Web application into smaller
functional groupings. An area is
effectively an MVC structure inside an
application. An application could
contain several MVC structures
(areas).
For example, a single large e-commerce
application might be divided into
areas that represent the storefront,
product reviews, user account
administration, and the purchasing
system. Each area represents a
separate function of the overall
application.