I'm just starting out in CompoundJs and there's a lot I still need to learn.
I'm just trying to figure out how Helpers work in NodeJS+CompoundJS, from what I've seen so far Helpers are intended to be used with Views and not so much with your Controllers.
However I would like to make a simple function that will validate the user input given in params (check if certain params are defined and optionally check if their value is valid).
Can anyone explain to me what would be the best way of implementing this? Keeping in mind that I will want to use this in many different controllers so it should be globally available.
Do i have to use custom validator or helper?
Validation is probably better suited for the model. You could also do lower-level validation in the controller. The helpers are just designed for exposing global variables to the view templates.
Related
I'm learning DDD (Domain Driven Design) and reading Clean Architecture. I found out about Value Objects and have been reading more about them and have implemented some in my application which could be found https://gist.github.com/Tyler0722/73ec826be814b8e54b9f6ae6ae836409.
Value Objects are created by calling the factory method which performs validation and follows the separation of concerns principle. The problem is I have two Value Objects where the validation logic is duplicated. Username and QuizTitle where the only difference is MAX_LENGTH which violates the DRY principle. I was wondering if anyone knew anyway I could make this DRY.
If you want to remove repetition you must be very careful.
The first question you should ask yourself is
What is the same and what is different?
Maybe you will find the same or similar structure like
check the props
create an error result or a success result
If you found out what you think the same is you have to ask yourself more questions:
Do the things that are (look) the same have different responsibilities?
Do they change for the same or for different reasons?"
These are the questions that are about the single responsibility principle. Sometime things look the same by accident. They look the same but are different, because they change of different reasons. If you eliminate the "duplication" in this case you will have more problems then you solve.
E.g. if you consolidate the validation logic of QuizTitle and Username into one method and later you get a change request for the QuizTitle validation you can easily break the validation behavior of Username. I guess it should not change if the QuizTitle validation changes.
You might also want to read the good article by Martin Fowler about Avoiding Repetition
My suggestion is to not do it. In this case it's just not necessary.
But if you want to do it anyway, you can build a Validation class with static functions. At my work we use Webmozart/Assert and if you take a look at its implementation you will understand what I mean. In my opinion there are very handy. Also you can pass the MAX_LENGHT as an argument.
Well, I agree with Darius Mann, that these value objects have similar business logic is ocasional, if they are different concepts in your app, keep them separated and independently, it is my opinion.
I am trying to institute DDD into a node.js application using es6. I am using mongoose for my data access layer. I noticed that mongoose has a ".methods" property tied to the model schema. In terms of adding business logic to an entity, would this be an ideal place to add business logic or should I consider creating another object that holds the business logic that mirrors the model schema object and just copy the data from one to the other? If I were using sequalize, what would be the preferred approach here?
I don't think there is really a definitive answer to this, but I'll give you some opinions.
A number of DDD related concepts and instruments are built around features exposed by OOP languages (in-particular: interfaces & IOC). In the JavaScript world, things tend to be a little different, particularly when leveraging the module system. That said, it's not impossible, but compromises might need to be made.
One of the more important points in DDD is that your models are "plain". They are completely ignorant of any persistence mechanisms, etc, they are simply just data and logic. By defining your models using Mongoose, you pretty much lose that; your business logic is being attached to a Mongoose schema object. But perhaps that is where you can compromise, it very much depends on how puristic you wish to be about it. Now, you can do mapping, as you suggested. If you do decide to go ahead with that idea, something like AutoMapper could help. I've been involved in a project that used ES7 decorators from cerialize for a terser approach (we weren't using schemas, however).
I am trying to do something very simple, but it is proving to be very difficult. I have two or more views(XIBs) that need to get access to the same data structure. In this case its a long list. I have seen suggestions to use singletons and appdelegates, but none of that seems to work. I cant figure out how a singleton gets instantiated in a mono type project, so all I see is the class. And I have no clue how to use an appdelegate to do this.
lets not argue the drawbacks of global variables. I understand this. And I dont want to pass the list as a parameter to the constructor of the view. The rationale being that the list is very long. This will just end up creating alot of big lists that are all the same. Global is what I need. Can someone send me a simple example of how to access just one variable from any view. lets say its an int located in main and I have two views, view1 and view2 that need to access it.
I use a static class to achieve something similar to this. It has properties for the different global values I need to track state, etc. I initialize the values when my app starts, then I can get/set them anywhere in my app by referring to the static class.
It's not necessarily the best solution, but it works and is simple to implement.
I'm facing several problems trying to apply DDD with EF4 (in ASP MVC2 context). Your advaice would be greatly appreciated.
First of all, I started to use POCO because the dependacy on ObjectContext was not very comfortable in many situations.
Going to POCO solved some problems but the experience is not what I was used to with NHibernate.
I would like to know if it's possible to use designer and to generate not only entities but also a Value Objects (ComplexType?). If I mean Value Object is a class with one ctor without any set properties (T4 modification needed ?).
The only way I found to add behavior to anemic entities is to create partial classes that extends those generated by edmx. I'm not satisfied with this approach.
I don't know how to create several repositories with one edmx. For now I'm using a partial classes to group methods for each aggregate. Each group is a repository in fact.
The last question is about IQueryable. Should it be exposed outside the repository ? If I refer to the ble book, the repository should be a unit of execution and shouldn't expose something like IQueryable. What do you think ?
Thanks for your help.
Thomas
It's fine to use POCOs, but note that EntityObject doesn't require an ObjectContext.
Yes, Complex Types are value objects and yes, you can generate them in the designer. Select several properties of an entity, right click, and choose refactor into complex type.
I strongly recommend putting business methods in their own types, not on entities. "Anemic" types can be a problem if you must maintain them, but when they're codegened they're hardly a maintenance problem. Making business logic separate from entity types allows your business rules and your data model to evolve independently. Yes, you must use partial classes if you must mix these concerns, but I don't believe that separating your model and your rules is a bad thing.
I think that repositories should expose IQueryable, but you can make a good case that domain services should not. People often try to build their repositories into domain services, but remember that the repository exists only to abstract away persistence. Concerns like security should be in domain services, and you can make the case that having IQueryable there gives too much power to the consumer.
I think it's OK to expose IQueryable outside of the repository, only because not doing so could be unnecessarily restrictive. If you only expose data via methods like GetPeopleByBirthday and GetPeopleByLastName, what happens when somebody goes to search for a person by last name and birthday? Do you pull in all the people with the last name "Smith" and do a linear search for the birthday you want, or do you create a new method GetPeopleByBirthdayAndLastName? What about the poor hapless fellow who has to implement a QBE form?
Back when the only way to make ad hoc queries against the domain was to generate SQL, the only way to keep yourself safe was to offer just specific methods to retrieve and change data. Now that we have LINQ, though, there's no reason to keep the handcuffs on. Anybody can submit a query and you can execute it safely without concern.
Of course, you could be concerned that a user might be able to view another's data, but that's easy to mitigate because you can restrict what data you give out. For example:
public IQueryable<Content> Content
{
get { return Content.Where(c => c.UserId == this.UserId); }
}
This will make sure that the only Content rows that the user can get are those that have his UserId.
If your concern is the load on the database, you could do things like examine query expressions for table scans (accessing tables without Where clauses or with no indexed columns in the Where clause). Granted, that's non-trivial, and I wouldn't recommend it.
It's been some time since I asked that question and had a chance to do it on my own.
I don't think it's a good practice to expose IQueryable at all outside the DAL layer. It brings more problems that it solves. I'm talking about large MVC applications. First of all the refactorings is harder, many developers user IQueryable instances from the views and after struggle with the fact that when resolving IQueryable the connection was already disposed. Performance problems because all the database is often queried for a given set of resultats and so on.
I rather expose Ienumerable from my repositories and believe me, it saves me many troubles.
So Meta Programming -- the idea that you can modify classes/objects at runtime, injecting new methods and properties. I know its good for framework development; been working with Grails, and that framework adds a bunch of methods to your classes at runtime. You have a name property on a User object, and bamm, you get a findByName method injected at runtime.
Has my description completely described the concept?
What else is it good for (specific examples) other than framework development?
To me, meta-programming is "a program that writes programs".
Meta-programming is especially good for reuse, because it supports generalization: you can define a family of concepts that belong to a particular pattern. Then, through variability you can apply that concept in similar, but different scenarios.
The simplest example is Java's getters and setters as mentioned by #Sjoerd:
Both getter and setter follow a well-defined pattern: A getter returns a class member, and a setter sets a class member's value. Usually you build what it's called a template to allow application and reuse of that particular pattern. How a template works depends on the meta-programming/code generation approach being used.
If you want a getter or setter to behave in a slightly different way, you may add some parameters to your template. This is variability. For instance, if you want to add additional processing code when getting/setting, you may add a block of code as a variability parameter. Mixing custom code and generated code can be tricky. ABSE is currently the only MDSD approach that I know that natively supports custom code directly as a template parameter.
Meta programming is not only adding methods at runtime, it can also be automatically creating code at compile time. I.e. code generating code.
Web services (i.e. the methods are defined in the WSDL, and you want to use them as if they were real methods on an object)
Avoiding boilerplate code. For example, in Java you should use getters and setters, but these can be made automatically for most properties.