i know this is pretty general, but i couldnt find any suited information regarding this topic:
we need to develop a module-based system (ASP.NET-MVC) that should be adaptable for multiple different customers. Each of the modules can be customized for every company.
Is there some kind of tutorial on how to handle such complex requirements? (multiple customers that can have different compositions of modules and different module-implementations)
Can you recommend an approach on how to represent this structure in TFS?
How can the enrollment be done when each customer can have a different composition of modules.
Is there a recommended tool to keep track of all the versions that are enrolled on the different servers (staging, customers, ...)?
Would be really glad if someone could shed some light on that topic or at least throw some hints on what to exactly search for!
I am not sure if there is any tutorials but MVC its like a Class lib with views.
You can devide to components lets say you have module called payment, this module will include controllers, scripts, and views. To use this module you can have 2 options, 1. Create nuGet package with all content. Other option is to create zip file with content and just copy all to your project.
To use it for each customer would be simple since you divide all to different modules, and then you can include or exclude from your project.
As i mentioned i would use private Nuget server to handle packages then its really easy to add remove components just with few click. Also you can add build server where you can run unittests and if everything passed sucessfully then publish new nuget package
Related
I like the way F# requires to organize files and code in order of dependency because it discourages mindless coupling.
I have flat list of source files atm (simplified):
Common.fs
Workflow1.fs
Workflow2.fs
And want to go one step beyond. First, organize files like this (VS 2017 can't move folders up and down, one needs to edit .fsproj but it is different story - at least it is possible):
Common.fs
Workflow1\Impl1.fs
Workflow2\Impl2.fs
I expected Impl1.fs and Impl2.fs to be fully isolated from each other because their folders are not in parent/child relationship, but Impl2.fs can easily see types and functions from Impl1.fs: just open module and they are available
Are there any techniques to keep them isolated? It's possible to split the project in three however I prefer to keep DLL as a unit of deployment: workflows are small and ideally I want to avoid to have many tiny DLL files.
It sounds like you have a good understanding of what your options are. You are not missing anything else. Consequently, the answer to your question is, "no."
You can't isolate the folders that way, as far as I know. However, if you want to keep them isolated at compile time but deployable as a single unit, you can create separate projects and use Fody or ILMerge to combine the assemblies post-compilation.
I have many projects in the same Centos server and I'd rather like to install ZF2 once in a location like /usr/share/zf2 instead installing it with Skeleton all the time as duplicate libraries with projects and use ZF2_PATH in all my applications. Naturally, I'd like to use composer to update this shared zf2 library as well.
I can make it work in my way but I'd like to know if there is a conventional/preferred way to do this.
What I would do is:
1- Install ZF2 in /usr/share/zf2
2- Set ZF2_PATH environment
3- Remove Zend Framework 2 requirement from composer.json of the projects and update all as necessary.
I am just trying to follow a proven/accepted/easy-to-maintain method instead discovering it.
Thank you very much.
This is unconventional, there is no "proven/accepted" way of doing it and many people will have different opinions.
Downside of your solution is the need of testing all 3 apps when upgrading Zend Framework, I am sure you can imagine multiple scenarios when it could be handy to upgrade it just for one. If anything goes wrong, and things do go wrong, you will end-up breaking all 3 apps, not just one.
The only upside is saving space, but is that really an upside any more? Isn't disk space very cheap. Breaking your code is definitely more expensive (I am talking about cost of your time, potential loss of data or users).
If you still want to proceed you can create a 4th project with its own composer.json file and use it for any shared dependencies.
VS2013, MVC5, VB
I am nearing the completion of a small project to manage the roles tables in a standard MVC5 application. The code is pretty much encapsulated. What are my options for using this 'package' in other projects?
Can I compile it into something? I know this type of action is possible, I'm just not familiar with the options available to me or the steps to do this. Links to sites that have tutorials are fine. Is creating a Nu Get package the only way to go, or is that even in the ballpark of what I'm asking. I say Nu Get, but I don't mean for public consumption, only for my consumption.
Will the finished 'whatever' include it's controller class, view models and views? Will I be able to easily manage updates? etc.
Creating a Nuget package is one way. I have created a local repository of common utilities for this purpose. But I usually use it just for DLLs. I use Nuget Package Explorer for its ease of use since its just me using the packages most of the time. Not sure its possible to place the files in specific directories.
Files in the content folder are copied to the root of your application when the package is installed. - Nuget
The alternative is to create an item template. I used to use this method for class files I want in my code but I can't see why you couldn't do it for the rest. Works well and isn't too hard to set up. There are dozens if not 100s of tutorials on the subject. Here is one on code project.
I have an app which I will call it the "base app". The app works with many brands.
I need now to separate those brands, and to make a distinct app for every brand.
Every app will have a slightly different design (including different images) and here and there maybe some specific-to-a-brand code.
All of the apps should also use the same base code from the "base app" that deals with logic.
I have some options I have thought, but I am not sure if any of them suit my needs. Will be happy for clarifying the difference among the options.
The options I have thought are:
1) Creating an app for each one of the brands and just copy-paste the class files from the "base app" as a reference, except the .xib files, which will be copied as a copy. The problem is that then I do not know how and where to write a brand specific code (because it will be shared among others).
2) Creating a workspace that will include the projects for each one of the brand. Not sure how this works and if this is correct, will be glad for help clarifying here.
3) Nest a "base app" project inside every brand's project. Any help clarifying what does it do will be appreciated.
3) Using the base app as a static library which will be linked in every brand's project. Not sure what will happen with the UI (shared, not shared). Will be glad for help clarifying here too.
4) Using a simple way of maintaining each one of the brand's project, including the shared code (which will be a disaster, I guess).
The simple solution in iOS is use targets.
For resources you can use different targets for each brand and then select different resources (images, xibs, etc) for each target.
Also if the changes in code are minimal you can then refactor some part of your code and create different classes with different implementation for each target (you can use some pattern like a Factory). Also you can simply use preprocessor macros.
It's not the better, but this is the simplest and quick approach, but if your code changes a lot it's better to create a core library like the other answers say.
A good approach would be to split your app up into the following components:
Core Model Library
Reusable views & view controllers. The views can be designed to support skinning and customization.
Any other reusable code that can be encapsulated as its own 'identity'.
These core projects should ideally have their own continuous integration (quality control) builds and tests.
And then use CoocaPods
Instead of manually performing all this complex integration, use CocoaPods. CocoaPods will create the Xcode workspace, build the libraries and link them into your project. You then create a custom build just by gluing the pieces together.
In addition to this, CocoaPods also performs tasks such as:
Resolving transitive dependencies - which just means building and fetching any libraries that your libraries themselves use.
Managing versions of the libraries being integrated.
Private Spec Repo is possible, or just use GitHub
The main CocoaPods repository is of course public and contains open-source and/or freely available libraries.
You can host your own CocoaPods spec repository, or simply set up a private GitHub account, and include a PodSpec in each project, then resolve as follows:
pod 'MyLibraryName', :git => 'https://github.com/myOrgName/MyLibrary.git'
this will install all of your libraries into your workspace. To update your project to include any changes to the core libraries, simply:
pod update
Advantages of this approach
You'll have a separate set of quality controls that gets applied to each core project.
There'll be much less reputation.
You can use more automation. More automation equals less waste equals more customer value.
As the team grows, you can split up core product devlopment and solution integration into separate roles/teams. A team working on an integration build, need not pull the latest library features, if that would disrupt them.
You can have two different customers on different builds of the core library. CocoaPods will manage this seamlessly. So you wouldn't necessarily have to update a build, until you get an enhancement request or scheduled maintenance. (Again reducing waste, thus increasing customer value).
Inspired by Piggly Wiggly (but lean through and through)
This approach is modeled after the production line style approach that was popularized in Japan after World War II. Its called Lean Methodology, and is all about having a fast, small inventory and reducing waste. (Delivering more with less). . Japanese execs got the inspiration for this when they went to America and visited Piggly Wiggly Supermarket stores.
This is often something you encounter creating cheap flash-games or apps.
These have very generic frameworks like: kicking a ball, shooting at the screen, or generating a list with some data downloaded from a specific server etc...
Everytime they want to create a new shootergame, they just load up their shooting framework, add a bunch of graphics and can release a crappy game within a day.
How do they do it?
They often create a framework which contains shared models, handlers, interfaces etc.
Put a lot of general utility functions like downloading files etc in a library.
And you can also create some default framework views and view-controllers.
When you want to create a similar app, just import the library and re-use the base framework. Containing base-views, base-models etc.
You can find a good example in the demo-examples delivered with the ios SDK or android SDK.
Good luck.
We are currently looking at the newest version (2.60) of NopCommerce in MVC and we will be integrating it pretty soon…We’ve downloaded the Source Code and paid the 20$ for the User Guide documentation. The documentation is great! I mean…it is great in the sense that it explains how to deploy, install and how to work around the UI Frontend and Backend. This is great for an overall overview but what it lacks is the understanding of how to work with NopCommerce as a team. What are/is the best practices etc...
As an example (or parallel), if you decide to work with Dotnetnuke as a team, you usually work in the following fashion:
Each developer downloads/installs Dotnetnuke locally on their
machine.
You also download/install Dotnetnuke on a dedicated server (let’s say
dev-server).
As a developer, you work and create modules which you test locally
within your Dotnetnuke installation.
Once it is done, you package your module (and any SQL scripts that
comes with your module) into a zip file.
Once the package is ready, you upload/install that package on the
dedicated server (dev-server).
This approach works great for Dotnetnuke and more importantly if you have a team of developers creating modules.
My question is how does a team work with NopCommerce MVC?
I’m assuming it is a bad idea to directly work within the source code in case your team decides to modify core elements/source which will make any upgrade to newer versions impossible (or break changes).
I’m not sure if my parallel to Dotnetnuke is a correct one…but would anyone have any idea (or help me clarify) how does a team work with NopCommerce MVC.
In addition, should the team only rely on creating plugins for NopCommerce and stay away from modifying the core or should this be irrelevant?
What about adding new objects in SQL (or modifying existing ones) should we prefix our objects in case an eventual NopCommerce MVC upgrade creates similar objects and/or overwrites them?
Thank you for helping me shed some light on this.
Sincerely
Vince
Plugins in NopCommerce are almost like modules in DNN. Depending on what you need to do, it sometimes is necessary to modify the core code.
What I've been doing for the Services is create a new class and inherit from the existing service, then override the function you want to change. Create a new DependencyRegistrar class and set your new service classes as the implementation for that particular interface. Also make sure the Order property is 1 so that your DR class is loaded after the stock one. Since you're inheriting from the core class, any functions you didn't override will be handled by the parent class. If I need to add a new function, I'm just modifying the interface, putting a stub in the stock class, and implementing it in my own.
Views in the Nop.Web project can be overridden by Themes. The Admin stuff and the Web Controllers get trickier. I'm just modifying those files directly.
The Core and Data classes can be done using partial classes to add your new fields.
In any case you will still need to merge changes with your solution when an update is released. My opinion is that you are better off writing clean, readable code now and bite the merge bullet when it comes.
I don't really worry about SQL scripts right now because I'm a single developer but maybe you add a folder for ALTER scripts and name them after the day they were created. Then each dev knows which scripts they need to run when they get latest.