I am trying to use Orchard extensible Framework as a base of my application.
I only want the framework and core modules but don't want any of the database access stuff.
Does anyone know how I can get rid of this database and configure it to not read from the database and lunch my module on startup instead of Orchard startup module
Thanks
You could (with considerable work) implement your own data access provider, but Orchard relies heavily on the database for everything at a core level: Settings, migrations, etc. You need the startup module for the Orchard context so that all of the framework and core modules can function. You would probably be better off customizing/overhauling everything on top of the core rather than trying to have your own module replace the startup module.
Related
What's the recommendation on grouping your business logic in Laravel? I find Laravel to be quite messy when it comes to large web applications. Should we continue to use Laravel default file locations or have anyone tried using a modular package like https://github.com/nWidart/laravel-modules ?
Laravel is a fantastic platform, not only for its elegant syntax and rapid development tool, but also for its community and open source packages. These bundles go a long way toward reducing development time.
Modules
Modules are like packages in that they have their own Models, Views, Controllers, Migrations, and other classes.
All Controllers and Models are placed in the app/ folder by default in a Laravel program, while Migrations, Seeder, Providers, and other components have their own folder.
These folders become inconvenient when the application develops. It becomes difficult to locate logic for a specific portion of the application.
This is where using a modular approach to large projects simplifies production and maintenance. You can build different modules for different parts of your application using Modules. Each module has its own set of configuration options, such as controllers, models, views, migration, seeders, and providers.
To use modules in Laravel, simply autoload the Modules folder using PSR-4 and you're finished. However, this will entail additional tasks such as registering a namespace for language, views, and configuration, as well as running the migration.
Laravel Modules
Installing Laravel Modules is similar to installing any other
package.
Laravel Modules provides Artisan Commands to create new Modules,
activate/deactivate modules, create migrations. Below is a quick
screenshot of the different artisan command it provides.
When you create a new module it also registers a new custom namespace
for Lang, View, and Config.
Lang::get('blog::group.name');
#trans('blog::group.name');
Apart from these it also provides useful Facade Methods, Module
Methods
And also can publish your modules similar to a package (document).
How we used Laravel Modules?
Initially, when we started working on a pos (point of sale) application we didn’t have an idea of creating different modules.
But as the requirements increased to have a plug-play Restaurant extension for it, the idea of making modular made more sense.
So after creating and adding restaurants and many other optional modules, we added a setting for each business to enable or disable different modules.
Module::all(); method was used to list different modules the application had.
Each business can enable or disable modules for them as per their needs.
We used a combination of Module: has(‘blog’); business settings to check if a module is available & enabled.
The Module (or extension or plugin) can be put in any other application to add the functionality.
This is a question about web based software architecture. I am a Hybris newbie, but as I understand it, you can create a full Spring MVC app in one Hybris extension. What is the value of breaking out components of that app into multiple Hybris extensions? Are there web app features or architectural value (e.g. maintainability, extensibility, performance, etc...) that you can only realize by using multiple extensions?
Thanks!
So Hybris is based on the concept of being flexible and modular, allowing new functionality to be plugged in where needed via extensions. An extensions is an encapsulated piece of the Hybris Suite that can contain whatever you need it to contain, I.E. storefront, hMC, backoffice, etc. By default extensions are completely independent, however you can create dependencies between extensions no problem.
Say you're building an application that you want to have a section in the hMC, a frontend and some functionality in the backoffice too. In general you would have 4 extensions here:
a core extension for the model, services, interceptors, etc
hMC extension
frontend extension, pluggable frontend
backoffice extension
The real value of extensions is they allow hybris to be flexible and modular allowing for easy migration from one version of hybris to another.
I am a beginner in magento and am working on creating a website using magento. I have noticed that magento has a good number of apis that expose all of the functionality that I would need to create an ecommerce website. So, I would like to use magento's apis to fetch data, but develop the UI separately without any dependencies on magento. I have found a lot of references that develop the website via magento theming, but not those where the UI is developed in a separate MVC and uses magento purely as service layer. Are there any problems/issues in my approach?
Edit: I have gained a lot of clarity on db performance issue in apis and how external caching can alleviate the issue, but I still don't understand the underwhelming use of magento as a service layer (i.e. fueling the website by using magento's apis), are they any other gotchas?
Here is how we overcame slowness in Magento APIs:
Created a Web service provider in J2EE, Spring MVC that acts as a proxy between Magento and end users.
J2EE Web service provider exposes pretty much all the APIs that Magento has but also supports JSON with REST along with SOAP & RPC.
J2EE Web service provider uses a document based database (MongoDB) to store a snapshot of product catalog in MongoDB.
J2EE Web service provider uses native MongoDB caching to serve data fast without running any expensive SQL queries.
To avoid dirty caching issues we created a hook in Magento Admin to push data into MongoDB whenever data changes in Magento.
This might sound like overkill to some but we have been able to achieve pretty high throughput without any slowness.
The Magento APIs are slow, you would encounter serious performance issues trying to run a site off of it.
Due to the complex nature of the EAV model, you may find it difficult to manage products through the API alone.
Are there any particular concerns you have about using Magento's own frontend? It is daunting at first but once you understand the layout system it's actually very powerful and customisable.
Technically it is possible to run a site only through the API.
The issue you might face is a practical one, instead of spending your time trying to learn all the API calls, you can learn how to implement your current UI in Magento.
The advantage to this approach is that you will also better understand how Magento works internally, thus allowing you to leverage it's functionality for your unique business needs.
Another issue is that when using API's you have a little less control over how things are processed / calculated, vs when working in Magento itself there is a lot of control over specifics.
I regularly see "session expiration" issues when accessing Magento's API, through both SOAP and XMLRPC. All my calls require exception handling to avoid halting execution. I imagine that alone would create a nightmare when building everything on top of the API.
The best answer you're going to get is to Load Test the API before you start coding. Log the tests extensively and look for errors. If you see errors on a normal basis that should answer your question. Even if you find documentation that says it's okay to do what you're trying, you're still going to have to tune the API to work properly under the load required to run the store.
It will be good to know what you're up against before sinking hours into development.
I learned to love how LINQ enables set operations on collections. I'm not saying that I plan to shun traditional RDMBS, because I do need it for reporting. There are NoSQL alternatives out there, but they seem to all need to fire up a separate service.
What I looking for is something local where a DLL can create a database and perform CRUD on it. As mentioned, I'm not going to report out of this, just internal data store. The main application that will be using it is in C#.
I'm hoping that someone can give me a lead. If not, if there is anyone willing, we can start a open-source project for it. I'm not interested in commercial products.
Thanks,
You can run RavenDB in embedded mode inside your .NET application - no need for external services or anything.
And RavenDB supports Linq....
I usually use database first appraoch to develop my asp.net mvc web application and then i map the database tables using entity framework,,, but this apprahc will make my web application works only under specific DB vender .
so if i use the code first approach and entity framework and i do all the buisness logic on the application layer (for example i do not use any stored procedures); will my application in this case works fine regardless of the database vendor ???
BR
For EF to work on other rdbms requires"drivers"to be written to support the platform. MS only supports MSSQL. I know there are oracle libraries for EF, but I don't know about any others.
That said, the only way to make sure your application is portable is to develop against all the libraries you hope to support and constantly test against all of them during development. Otherwise it's just a pipe dream.
Of course, you can do the same thing with ADO.NET using ANSI SQL.