I am new to Zend Framework and currently struggling with the implementation of Model. Actually, what I want is as follows:
I have two tables (am using MySQL):
Musicians(id, name)
Albums(id, musician_id, album_name)
Now, I want to design the model, so that I can create an efficient join query in there.
I have tried many things, but am unclear about various things. For example, currently I have created a Table class (which extends Zend_Db_Table_Abstract), a model class and a model_mapper class. I am not sure, what code to put in which file and how actually I am going to call the model functions (containing the query result) in the action function in controller.
Any help is highly appreciated.
There is no single answer to this question. The best code to put in each class is based on the application logic your requirements call for.
There are methodologies to guide object-oriented design:
GRASP
SOLID
Domain-Driven Design
This free e-book has an introduction to DDD: Domain-Driven Design Quickly
Related
I am full-stack developer and currently study in software engineering in the university 2 course. Currently I am working on a Bookstore project using spring boot for back and React for frontend. So I need to implement 5 software design patterns in my project. However I don't now how to do such implementations and not yet experienced. So I need your help. How I can implement this?
First of all I am not here to demotivate you or anything else, what I will suggest you to start making a class diagram and from that class diagram you will notice somethings that will look weird to you, so the things that will look weird to you will be things that will required the implementation of the Design Patterns.
There are basically three types of Design Patterns Creational, Observer and Behavioral. So, as soon as you will create the Class Diagram, you will notice some base cases such as one class should use the single database object or same logic on a single time that is the place where you will be using the Singleton Design Pattern.
Let's say you have created a Class Diagram such that one parent class should not be able to create the objects of other class but the subclasses should do that kind of work, so this is the classic example of Factory Method design pattern and so and so on.
I wish you best of luck for your project as well.
I am implementing Repository Pattern in a large scale laravel app. I have put almost all sophisticated and reusable database logic in these model repositories and i feel its helpful and more organised. All the entity creations, retrieval etc code live in these repositories now.
But my confusion is: what should I do with the custom eloquent methods, for example I have a model with methods such as $model->canPerformXTask(), $model->isActive(), $model->hasTooltip() etc.
There are instances where I just want to use these methods to perform some logic in controllers or services. What should I do with these if I am implementing Repository Pattern ?
Should I create these methods inside ModelRepository?
Is it okay to have db logic in repositories but also use the eloquent models outside of it ?
Does having a repository pattern means "use eloquent models within the repositories only?"
Any insight on this will be very helpful...
I think it's more an opinion answer for everyone, and the debate will never end on this topic.
But, there's an expert answer by Povilas Korop on his youtube channel "Laravel Dialy" where he talks about this topic. you can find it with
"Laravel Code Review: Why NOT Use Repository Pattern?"
I am currently referring to a code sample in this website.
However i saw that he used both views and modelview. Then, i've come across a blog that stated among the 10 do's and don'ts for faster SQL queries, don’t use ORMs (object-relational mappers) when i searched for ORM code samples, it seemed like entity framework. So, is this a wise example to follow? Or should i just stick to simple queries? Because, the thing is, in my project, a function has to query multiple tables.
Should i stick to code-first but implement conventional querying? Or is it alright to follow the website i showed?
ADDED
Is this tutorial following 'best practices'? I found this when i searched for DTO tutorials. I was wondering since its concept looked similar to AngularJs, should i implement either one of them or could i implement both together?
Is there a way, given a database or some other source specification for an application, for an entire WPF or Silverlight / XAML application to be generated that emits best practices?
For example, assuming I have a well-normalized database (or some other kind of base specification for an app), is there a tool that can create a well-formed MVVM application. This would include...
XAML (Views) for all of the tables (list and edit) with no code-behind
ViewModels that emits properties extracted from the db schema along with commands or behaviors for all of your standard CRUD operations
Models built with the repository pattern (or some other db abstraction) with interfaces that emit the table design and relationships and a default implementation of your choice (sql, sql ce...whatever).
An ideal tool like this would only do a "first pass" of the application after which the developer would make all necessary changes and modifications.
I don't think there is any such tool but it seems like a tool like this should be possible.
Another related question, in the absence of such a tool (or even if there is one), what tool(s) are best used to get me from a database design (or some other kind of base specification for an app) to working app.
What STEP-BY-STEP process do you take to get from design to basic working application in a couple of hours?
I am just trying to figure all of these practices and patterns and I am getting a pretty good grasp of the pieces but not sure what workflow to use to make it all work together quickly but still allows unit testing of separate concerns.
Thanks in advance.
Seth
Not sure if this is what you are looking for, but you can use LightSwitch
From a process perspective, I build and test my ViewModels first. That allows a division of labor between designing and wiring up the UI and pulling data into the ViewModel.
I am developing an application in WPF using the MVVM pattern. If I have Student as a data model, for example, where could I add the business logic like adding new Students, deleting Students and updating Student info, calculating marks and so on?
Does all the business logics come under the model or the viewmodel?
If it is in the model how can we do that? Any example code please? I need full code for an example!
Business logic should be part of of your model, as all of that code should be reusable across different technology platforms. For example, you may want to reuse your models across a web site in ASP.NET MVC, and a desktop application in WPF, so it wouldn't make sense to have business logic in your view models.
View models should contain presentation logic which is specific to that particular application instance.
As for example code, this will be specific to the domain that you are modelling, so you would have to ask a more specific question about what you are trying to model.
I suggest you read PRISM documentation on this subject: Chapter 5: Implementing the MVVM Pattern.
Even if you don't plan to use PRISM, the article is very well written and details the pattern in Microsoft's technology terms.
I would trust very little of what Microsoft has to say on Patterns as their articles are often dated, or modified to support their own proprietary frameworks or products. Also I've found MS thoughts/approaches contradictory within their different teams and also within the generally accepted approach in software.
Not all of it is good and not all of it is bad basically.
To answer your question. I'd use a Service for Business Logic. I'd instantiate a reference to it in the ViewModel and I would not put any logic in either the ViewModel or the Model that did not have anything to do with their role. ie Presentation logic is okay dependingon what it is, it might be best placed in the ViewModel as it is highly tied to the View in question. Same goes for the model.
Keeping in mind these roles you will have a scaleable and testable application.