How do you commonly lay out your solutions in Visual Studio? Recently, I've kept the BLL, DAL and presentation in different classes and planned to add a test solution as I learn TDD. However, after recently watching a video from Rob Conery and viewing a project from an external contractor, I noticed a theme of multiple projects in the solution.
The projects included in the solution were:
Infrastructure
Model
Web
Tests
SQL Repository
Is this something new or a design technique suggested for MVC? Can anybody tell me more about this design?
First, you need to understand Rob's coding habits. He uses an MVC-esque approach to development (if not pure MVC) and uses his ORM SubSonic.
The use of MVC is the reason for the "Model" class, since SubSonic 2.1 contains Migrations, he is using the SQL Repository for those migrations, so that he can version his DB.
Tests and Web are self-explanatory, which only leaves the Infrastructure, and your guess is as good as mine, though it could be the "Controller" of the MVC pattern.
It all depends on the pattern that you're using, your own preferences for separation of concerns, and your comfort level developing multiple projects at once.
Related
I have a VS Project/Solution (.NET 6.0) that contains a ton of core functionality. WinForms, Classes, etc.
My intention is to copy/duplicate this project and customize it for each individual application (if you are curious, this is a project interacting with collaborative robots. While the core of the project will be similar across multiple robots, each individual robot will need its own tweaking (GUI, functionality, etc). I would like to keep these as individual projects and not just add new robots to the base project. I want to keep it to one project per robot. I have my reasons, from licensing to support.
My question is: what is the best practice way to copy/duplicate a project and rename it? These are the goals:
Keep the Base/Ref project intact so it can be used as a basis for new projects.
Be able to push each 'new' project to a new location/repo in GitHub.
Any thoughts are greatly appreciated!
I am a bit confused about the differences of these two strategy.
Which is the guideline if I would like to share a java library among different java Apps ?
Regards,
S.
Not sure if a general guideline exists, but happy to share how we use the two in our company.
We use multi-project builds to organize the different parts of our product. For example, we have subprojects for the business logic, the rest api, the webapp, the mobile app, and the user manual.
In contrast, when working with software our product depends on, but isn't part of our product, using a composite build can be useful. For example, our product's webapp is based on a framework. For official releases of our product, we rely on the official releases of the framework only. However, in development we sometimes want to test a bugfix in the framework that has been applied to the framework's code base but that hasn't been relased yet. A composite build allows us to build the framework from source and run our product against that build.
I have been writing an E-shop project for a customer and now I have signed a new similar contract with another customer. I was wondering what would be the best practice to continue the first project while staring the second so that the reusability is at maximum?
One way would be to change the first project to read all menu items, slider pictures, ... from the database so that I can deliver the same project to both customers with different databases. The benefit of this approach is that I have to manage only one project, but it leads me to gradually write a CMS, which is a time-consuming task.
The other solution would be to use Git. For example, I would fork the base project into two different projects. If the functionality I am writing is the base one, then I would push it into the base project; otherwise, I push it into the appropriate forked project.
Which one is a better approach in your opinion? Or you guys have any better idea?
Cheers,
Habib
There are a few things that need to be considered.
First of all, This project as you said has the capability to be sold more. So, you must think about how much is possible to make it dynamic via Configuration files, Hooks & Plugins to make the modification to the functionalities of the project through that. I know you have considered this already.
Second, Using a Core Repository and different forks for customization. (It's a great idea but needs proper discipline, workflow and manpower to make sure everything is fine-tuned and works properly )
It's highly recommended to make your application cloud-native and provide proper UAT/QAT Environment for test before launching on the production, And also implementing Test cases to be checked within the Git and CI/CD pipelines in order to prevent issues in the merge process.
I'm not certain about what you want, but if you want to develop an enterprise project that contains many features such as wallet, tracking, payment,... I think you can implement each service as a microservice and integrate all of them.
About git, I think it's better just for handling the source code and you had better use git module for handling microservice and just using branches for developing process
I have finally found some solutions that I would like to share with you guys. Let's divide differences into 2 big categories of data differences and code differences:
Differences in data
If the database in each project is different (e.g., the product has some features in one project and some other features in another project), then the best solution is to use NoSQLs such as MongoDB. In the first place, NoSQLs are designated to support databases that don't have well-defined data structures, and you don't know what features you may add to each entity at present or in the future. It completely applies to my scenario that each shop may have a different data structure. However, since my project is based on Laravel and it does not have built-in support for MongoDB, I have decided to design some key-value tables that haven't been so bad so far.
Differences in the code
Regarding differences in the code, I would definitely suggest branches in Git and other functionalities provided by Git repositories such as Gitlab repository mirroring. Each feature has a different branch in my code, and I can provide each customer with different functionalities by merging those branches I want to deliver to the customer.
All in all, you may take as much business logic as you can into the database since changing it in the future is more straightforward. On the other hand, you'd better keep themes in the code because every customer likes a different theme, and changing them in the code is easier than taking them to the database.
What is the preferred solution for Exrin project layout when adding a database?
The sample Tesla app had a separate project for the Services and another separate app for the Repository. With the removal of both of those projects in the latest template, it makes the most sense for it to go within the Logic project, but I'm curious if the author had a different preferred implementation.
The Tesla Sample project is designed for a very large app, and Service and Repository don't need to be separated out into a separate project, they can all be referenced directly in the logic app, as per this diagram.
This is the project setup, I now recommend for most projects.
I have a "core" project developed in RoR. The problem is that there are several independent projects which have this "core" as they based code, and then they may have new functionalities or changes in views, helpers, controllers, etc. I want that any change in the "core" can be tracked by these other projects. Hence, any change in the "core" will be replicated, or not, on the other projects. I was thinking in gemify the "core" project, but due to the constant changes that the other projects have, this wouldn't be the best solution (is a long process too). That's what I think. Other solution would be to separate some important code into modules. Then I can import this new features in the projects which want to use them.
The "core" project is a pure MVC ruby on rails project.
What do you suggest for this issue?
Thanks in advance.
We have about a hundred Rails sites, each customized from a core engine gem included in all of them. Groups of related sites also use a secondary engine gem. See Rails Engines.